Re: existing work on TODO items

[Ken Manheimer]

On 1/10/06, Richard M. Stallman <address@hidden> 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.