emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Outline mode


From: John J Foerch
Subject: Re: Outline mode
Date: Tue, 04 Sep 2007 11:58:31 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:
>
> 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.
>
> 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

Sure.  I want the heading line of a collapsed entry to be editable
independent of the entry.  The newline at the end of the header should
belong to the header, so when point is there, there can be no funny
surprises about doing things like backspace.

The reason I don't like the idea of modifying move-end-of-line, or
rebinding my C-e key in outline-mode, is that that command is only one
of many possible ways to put point on that character.  I would find
that very inconsistent indeed.

If I may go back to the implementation side of it for a minute, I
would like to share some thoughts I had this morning.

When I think of the logical parts out of which an outline is made, I
think of blocks composed of two parts: headers and entries.  But the
current implementation is in terms of blocks composed of three parts:
a header (with no newline), an entry, and a terminating newline.

The current implementation was made necessary because the code that
places the ellipsis always places it at the point of the invisible
text.  Thus in order to have the effect of the ellipsis being on the
same visual line as the header, you have to say that the newline after
the header is actually part of the entry, and you have to leave the
final newline from the entry unhidden.

An invisibility-spec looks like '(outline . t).  The t signifies that
an ellipsis will be displayed in place of the invisible text.  My idea
now is to add a feature to the invisibility code that lets you give a
function in place of that t.  The function would be called with two
arguments--the region being made invisible--and the function would
return the point where the ellipsis should be displayed.  This would
let outline-mode have an option to leave the header's newline visible,
and hide the final newline of the entry.  The function given in the
invisibility-spec would return the location of the header's newline as
the location to display the ellipsis.

--John









reply via email to

[Prev in Thread] Current Thread [Next in Thread]