Re: Outline mode

[Stefan Monnier]

> 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.

Check the docstring of move-end-of-line and you'll see that the current
behavior has a reasonable justification: it tries to ignore newlines that do
not correspond to a screen newline, e.g. newlines that are in the middle of
a `display' property showing a picture, or newlines that are `invisible'
specifically to give the illusion of having a single line.

But I agree that in the case of outline-mode, the move-end-of-line behavior
is not quite right: it should stop at the end of the heading since it is
visually the end of the line (with an "inaccessible" ellipsis appended to
it).
If people aree with this assessment, we can adjust the behavior of
move-end-of-line accordingly.

> 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.

I don't understand what you want.  Can you try and express it in terms of
user-level visible behavior rather than in terms of low-level
implementation details?


        Stefan