On 1/10/06, Richard M. Stallman <[EMAIL PROTECTED]> wrote: > - allout diverges enough from outline-mode code, both internally > and in external behavior, that i think some changes to outline.el > would be required to retain desired allout behaviors. those > changes could quite possibly be extensive. > > It might be worth making substantial change to outline.el if > (1) the resulting code is clean, and > (2) the result would enable allout.el to be based on outline.el. > > - curious about potential performance issues, i transformed an > allout outline which i work with most frequently (my 1.2 MB > daily activities log - which i'm often editing, every day) to > outline-mode format (changed the headers prefix), and i > noticed some severe performance problems which are absent > in allout-mode. > > That is a different and unrelated question. For allout.el to be > based on outline.el does not necessarily mean that allout.el would > insist that outlines have the format that works with outline.el. > > What I have in mind is that allout.el would keep all its functionality > including the range of formats that it handles. The change would only > be internal. > > Such an internal change would be an improvement if the code is clearer > (while still doing the same job).
i think there's a misunderstanding here. the transformations i mentioned were not made because i was expected i would have to use outline-mode's format if i were to base allout-mode on it - i understand that i might, for example, use only outline-mode's `outline-flag-region', thus preserving allout-mode's policies but switching over to invisible-text overlays rather than selective display. the reason i made the transformations was to have a large outline in both the formats that is otherwise identical, so i could compare performance. those performance comparisons turn out to be important, presenting a quandry i'm facing in just that very basic transition - using invisible-text rather than selective-display. i noticed that any keystrokes - navigation, inserting text, etc - in an outline-mode buffer with a large amount of collapsed text (closed topics) has severely noticeable latencies. this is not the case an identically collapsed allout-mode outline. moving forward a character within the collapsed outline-mode outline takes more than two seconds per keystroke, while i can't measure the delay in the allout-mode buffer. (these delays occur everywhere, including movement across exposed text without crossing any invisible text.) the issue here is that the problem appears to be with the use of invisible-text overlays. i have made some exploratory adjustments to allout to use invisible overlays instead of selective display, and am noticing similar delays - one second per character, rather than between two and three seconds that i noticed in outline-mode. these delays would cripple my most frequent editing activity - adding notes to my daily log - and in general would reduce the scale of outlines that i could edit. (i should note that my system is a comfortably fast 2.0 Ghz notebook, though the situation is complicated by the fact that i'm running emacs withing gentoo linux in a VMware VM. still, the essential issue is the relative performance of allout-mode to outline-mode, and i think the speed in my enviroment is representative of a comfortably fast notebook...) so, the question becomes whether the switchover to invisible-text overlays would be a step back, and/or whether the interactive delays i'm noticing could be easily mitigated. one thing i wonder is whether the delays might depend on the number of overlays? if so, and if it's not already happening, it might significantly reduce the problem to have adjacent overlays automatically consolidated so that the total number of them is kept to a minimum. is there any conventional experience with and wisdom about the dynamics of overlays, in this regard? > altogether, i would prefer to continue directing my effort towards > evaluating and, if it looks promising, developing a widget-based > outliner, rather than spending any time consolidating the allout and > outline.el code base. > > I am not quite sure what a widget-based outliner would look like, > so I don't have an opinion. whatever happens with selective-display vs invisible-text overlays in allout-mode, i will be exploring the use of widgets and am hoping to have something nice to show eventually. _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
