Re: Outline mode

[John J Foerch <jjfoerch@earthlink.net>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Your code is really a big hack and the problems I mentioned are just one
> of many.  You can cover those up by adding more hacks, which will just leave
> other holes, etc...
>
> This said, my assessment of the problem as being a redisplay problem isn't
> right either.  It seems this redisplay problem was fixed a while ago, so
> really I don't see what problem you're talking about.  Maybe the problem
> you're referring to is that C-e doesn't go to the end of the heading (when
> folded) but to the end of the entry (which is why point ends up after the
> ellipsis).  This is a feature implemented in move-end-of-line.  Maybe you'd
> want to rebind C-e to end-of-line rather than move-end-of-line.
>
> Or maybe move-end-of-line should be changed so as not to jump to the end of
> the entry in this case (i.e. to stop before a hidden text if that text is
> covered by an ellipsis and is followed by a newline).  I'd tend to agree
> with such a change.
>
>
>         Stefan

Okay, now that I know that outline-mode's behavior is not a bug (only
a peave), I agree that my side-stepping the invisibility-spec ellipsis
is a hack.  Yet I don't like this idea of changing the movement
commands to make it more difficult to move point to certain
characters, either.

The basic thing that I want to implement is to make outline mode
collapse in a way that fits with how I naturally think about
outlines--the header is one complete line that can be edited as
normally as you would edit any line in any text file, and the entry
consists of all the lines below it, until the next header.  The
ellipsis code related to invisibility-spec does not accomodate this
well, because it would place the ellipsis on the line after the
header--clearly not a nice looking format.  That is what led me to
implement separate ellipsis handling in outline-mode--a clear mistake.

So is the following an agreeable solution?  Modify the
invisibility-spec code to allow the ellipsis to be placed one
character before the invisible text, via a third parameter in
invisibility-spec.  This would allow the entries to be collapsed in
the way I described, while still allowing the ellipsis to appear on
the same line as the header, and without the hack work-arounds.

This still has the problem of compatibility with derived modes, some
of which (like org-mode if I recall) explicitly depend on the header's
newline being invisible, and the entry's newline being visible.  For
this problem, I suggest writing whatever abstractions are necessary in
outline-mode, so the point-arithmetic in the derived modes can be
replaced by function calls, and thus accomodate both ways of hiding
entries.

--John