Outline mode

Outline mode

[John J Foerch]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

Hello,

Outline-mode has a problem that I would like to fix.  To see the
problem, hide an entry (C-c C-c) in an outline-mode buffer, and put
point at the end of the heading with C-e.  Point will then be located
to the right of the ellipsis, and as far as emacs knows, point is on
the last line of the hidden entry.  Typing characters or hitting
backspace, and many other commands will affect the last line of the
entry.

When an entry is collapsed in outline-mode, what actually gets marked
invisible is everything from the newline of the heading to the
character before the final newline of the entry.  It would make more
sense, if the newline of the heading were left visible, and the final
newline of the entry were hidden.  The ellipsis can be placed in the
buffer by using the 'display property on the newline of the heading.

The code attached to this email implement this behavior, and I hope
you will try it out.

However, there is a large problem with fixing outline-mode.  The
problem is that many of the modes that derive their behavior from
outline-mode probably depend on the current way that entries are
hidden.  I am hoping that I can get advice from more experienced emacs
developers on how to go about this project.  I am also hoping to get
help from the maintainers of as many of the derived modes as possible.

Thank you,
John Foerch
aka RetroJ in #emacs



[-- Attachment #2: update for outline-mode --]
[-- Type: application/emacs-lisp, Size: 11698 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Outline mode

[Stefan Monnier]

> Outline-mode has a problem that I would like to fix.  To see the
> problem, hide an entry (C-c C-c) in an outline-mode buffer, and put
> point at the end of the heading with C-e.  Point will then be located
> to the right of the ellipsis, and as far as emacs knows, point is on
> the last line of the hidden entry.  Typing characters or hitting
> backspace, and many other commands will affect the last line of the
> entry.

Yes.  That's a known shortcoming in the redisplay engine: the cursor should
be drawn to the left of the ellipsis to better reflect the position of point.

> When an entry is collapsed in outline-mode, what actually gets marked
> invisible is everything from the newline of the heading to the
> character before the final newline of the entry.  It would make more
> sense, if the newline of the heading were left visible, and the final
> newline of the entry were hidden.  The ellipsis can be placed in the
> buffer by using the 'display property on the newline of the heading.

I don't think that's a good idea in general: it forces every entry to span
at least two display lines: one for the heading and another for the
ellipsis.  In some contexts it might be accpetable, but definitely
not always.

> However, there is a large problem with fixing outline-mode.  The
> problem is that many of the modes that derive their behavior from
> outline-mode probably depend on the current way that entries are
> hidden.  I am hoping that I can get advice from more experienced emacs
> developers on how to go about this project.  I am also hoping to get
> help from the maintainers of as many of the derived modes as possible.

Maybe you could make it an option.


        Stefan

Re: Outline mode

[John J Foerch]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> I don't think that's a good idea in general: it forces every entry to span
> at least two display lines: one for the heading and another for the
> ellipsis.  In some contexts it might be accpetable, but definitely
> not always.
>
>
> Maybe you could make it an option.
>
>
>         Stefan

Actually, with my patch, the ellipsis appears on the same line as the
heading.

--John

Re: Outline mode

[Stefan Monnier]

>> I don't think that's a good idea in general: it forces every entry to span
>> at least two display lines: one for the heading and another for the
>> ellipsis.  In some contexts it might be accpetable, but definitely
>> not always.
>> Maybe you could make it an option.

> Actually, with my patch, the ellipsis appears on the same line as the
> heading.

Duh, I overlooked this "detail", sorry.
But then in what way does it help?  You may now move the cursor to just
after the ellipsis but actually be placed right after the newline (rather
than at the end of the text).  And if you remove the newline, you get into
the undesired situation where there is no ellipsis any more to warn about
the presence of invisible text.

Of course I'm biased: it would break reveal-mode which I wrote and use
extensively with outline-minor-mode ;-)


        Stefan

Re: Outline mode

[John J Foerch]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Duh, I overlooked this "detail", sorry.
> But then in what way does it help?  You may now move the cursor to just
> after the ellipsis but actually be placed right after the newline (rather
> than at the end of the text).  And if you remove the newline, you get into
> the undesired situation where there is no ellipsis any more to warn about
> the presence of invisible text.
>
> Of course I'm biased: it would break reveal-mode which I wrote and use
> extensively with outline-minor-mode ;-)
>
>
>         Stefan

The ellipsis is implemented as a display property in an overlay on the
newline of the heading, so point can be just before the ellipsis, and
still be on the same line as the heading.  If you move point past the
ellipsis, then point will be in the first column of the next heading.

Thank you for mentioning deletion of the heading's newline.  I hadn't
considered that situation, but now I have updated my patch to handle
it, as well as other situations where invisible text could get
modified.  I will attach the new version to this message.

That's cool that you wrote reveal-mode.  I want to help update it to
make it work with my changes to outline-mode.  I really think my
changes are an improvement, but I also see that it will take patience
and effort to make sure it works perfectly.

It seems that the best way to proceed will be to add sections to this
elisp file for each mode that needs to be updated.  Then all the
changes for everything can be in one place, and people can use
eval-buffer for testing, until it's finished.  I can put the relevant
`require's at the top of the file to avoid problems with autoload.

--John


[-- Attachment #2: outline-patch version 0.2 --]
[-- Type: application/emacs-lisp, Size: 13568 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Outline mode

[Stefan Monnier]

> The ellipsis is implemented as a display property in an overlay on the
> newline of the heading, so point can be just before the ellipsis, and
> still be on the same line as the heading.  If you move point past the
> ellipsis, then point will be in the first column of the next heading.

> Thank you for mentioning deletion of the heading's newline.  I hadn't
> considered that situation, but now I have updated my patch to handle
> it, as well as other situations where invisible text could get
> modified.  I will attach the new version to this message.

> That's cool that you wrote reveal-mode.  I want to help update it to
> make it work with my changes to outline-mode.  I really think my
> changes are an improvement, but I also see that it will take patience
> and effort to make sure it works perfectly.

> It seems that the best way to proceed will be to add sections to this
> elisp file for each mode that needs to be updated.  Then all the
> changes for everything can be in one place, and people can use
> eval-buffer for testing, until it's finished.  I can put the relevant
> `require's at the top of the file to avoid problems with autoload.

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

Re: Outline mode

[John J Foerch]

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

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

Re: Outline mode

[John J Foerch]

Stefan Monnier <monnier@iro.umontreal.ca> 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

Re: Outline mode

[Stefan Monnier]

> 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

Does the patch do what you want?


        Stefan


--- orig/lisp/outline.el
+++ mod/lisp/outline.el
@@ -708,7 +708,10 @@
 If FLAG is nil then text is shown, while if FLAG is t the text is hidden."
   (remove-overlays from to 'invisible 'outline)
   (when flag
-    (let ((o (make-overlay from to)))
+    ;; We use `front-advance' here because the invisible text begins at the
+    ;; very end of the heading, before the newline, so text inserted at FROM
+    ;; belongs to the heading rather than to the entry.
+    (let ((o (make-overlay from to nil 'front-advance)))
       (overlay-put o 'invisible 'outline)
       (overlay-put o 'isearch-open-invisible
 		   (or outline-isearch-open-invisible-function

Re: Outline mode

[John J Foerch]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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
>
> Does the patch do what you want?
>
>
>         Stefan

No.  It does fix a bug, but not the one I described.  Side note- with
this patch, there is still a problem when you use `hide-sublevels'.

I'll see what progress I can make implementing what I described in my
last message.  I will be away for a few days, but will be able to
spend time on it next week.

--John

Re: Outline mode

[Davis Herring]

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

Agreed.  With that change, the place where C-e goes now could be reached
by C-n C-b (with `line-move-ignore-invisible' non-nil, which it is in
Outline mode).  Without it, the place where C-e would go with it cannot be
reached except by something as complicated as C-s C-q C-j C-b, or M-x
search-forward RET C-q C-j RET to avoid unhiding the entry.

With that change, is there even an issue anymore?  I'm not sure I
understand all of the original complaint.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Outline mode

[John J Foerch]

"Davis Herring" <herring@lanl.gov> writes:
>
> Agreed.  With that change, the place where C-e goes now could be reached
> by C-n C-b (with `line-move-ignore-invisible' non-nil, which it is in
> Outline mode).  Without it, the place where C-e would go with it cannot be
> reached except by something as complicated as C-s C-q C-j C-b, or M-x
> search-forward RET C-q C-j RET to avoid unhiding the entry.
>
> With that change, is there even an issue anymore?  I'm not sure I
> understand all of the original complaint.
>
> Davis
>

This would only introduce more inconsistency to what is already there.
In my original posting, I only gave C-e as an example of how one might
get to the location I was talking about, not as the only command I
ever use to put point in that location.  The problem is not with C-e.

The problem is that the newline after the header is part of the entry,
and the newline before the next header is not part of the entry.  I
would like an option to have it the other way around, and I'm willing
to go so far as to write a new mode so I can have it that way.

I achieved the effect I want in the patch I posted, by an admitted
hack--bypassing the low-level ellipsis code, and implementing new
ellipsis code in outline.el.

But to implement this feature correctly, the low-level ellipsis code,
mainly in xdisp.c, if I am not mistaken, would need a new feature
added.  The new feature is to allow invisibility-spec to control where
the ellipsis would be displayed, instead of always displaying it at
the point of the invisible text.

If adding this feature to the low level ellipsis code is too
complicated, I would rather live with my hack method in my .emacs than
to see the behavior of C-e changed.  That said, I am studying the
low-level ellipsis code to see what I can make of it.  I'm not very
familiar with emacs' C codebase, so it all looks a bit hieroglyphic to
me at the moment.

Thanks to everyone who has taken an interest in this problem.  I
appreciate it very much.  It is a more complicated problem than I
originally thought, but I would rather take a longer time and fix the
fundamental problem in the ellipsis code than add a cosmetic hack to
outline.el or move-end-of-line.

--John

Re: Outline mode

[Davis Herring]

>> With that change, is there even an issue anymore?  I'm not sure I
>> understand all of the original complaint.
>
> This would only introduce more inconsistency to what is already there.
> In my original posting, I only gave C-e as an example of how one might
> get to the location I was talking about, not as the only command I
> ever use to put point in that location.  The problem is not with C-e.
>
> The problem is that the newline after the header is part of the entry,
> and the newline before the next header is not part of the entry.  I
> would like an option to have it the other way around, and I'm willing
> to go so far as to write a new mode so I can have it that way.

I'm sorry if I'm asking you to repeat yourself, but I (approximately like
Stefan) would like to see the UI idea instead of the implementation.  In
my case, though, I'm asking for a (re)description of the UI problem, not
any UI solution.  To make sure we understand the reference case, consider
this case, with the C-e that I'm supporting:

* Header
** Subheading, with elided body...
** Subheading
Shown body.

You can on the second line press C-e (or C-f), have point just after the
'y' in "body", and then proceed to edit as you like, appending to or
shortening the heading.  (Stefan recently put forth a patch to make the
invisibility overlay front-advance to allow the appending case to work
right; I think it should also be rear-advance.)  It's my understanding
that currently a redisplay bug causes the cursor to be displayed after
rather than before the ellipsis, but this is of course cosmetic.  The only
bad thing seems to be that isearch will still unhide the body if we use it
(C-s C-q C-j RET or so) to reach the end of the heading.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Outline mode

[John J Foerch]

"Davis Herring" <herring@lanl.gov> writes:
>
> I'm sorry if I'm asking you to repeat yourself, but I (approximately like
> Stefan) would like to see the UI idea instead of the implementation.  In
> my case, though, I'm asking for a (re)description of the UI problem, not
> any UI solution.  To make sure we understand the reference case, consider
> this case, with the C-e that I'm supporting:
>
> * Header
> ** Subheading, with elided body...
> ** Subheading
> Shown body.
>

No problem.  At "** Subheading, with elided body...\n" the newline
after the ellipsis is the newline character just before the next
subheading.  Users should definitely not be prevented from placing
point at this character, because it is an ordinary visible character,
and people may have any number of reasons for wanting to put point
there (maybe they just want to `describe-text-properties' for some
reason).  Thus, the movement commands are not the problem.

However, it would be preferable, at least to me, to have that newline
be invisible, and the newline immediately after the header to be
visible, so that when I go to the end of that heading line, by
whatever method, point is truly *on* the heading line.  Not having to
arrow to the left saves me both keystrokes and cogitation.  The reason
emacs cannot do this right now, is that if you hid that newline, and
displayed the newline after the header instead, your outline would
look like this:

* Header
** Subheading, with elided body
...**Subheading
Shown body.

In that case, you could put point at the end of your subheading, and
edit with no funny surprises.  Derived modes would also see that you
were in fact on a header-line (this problem is illustrated by
org-cycle in org-mode, which can't cycle if point is to the right of
the ellipsis).  But of course that outline looks silly.  We expect the
ellipsis to appear on the header line.

For outline-mode to work as I would like it to work, the invisible
entry needs to collapse at column 0 of the line after its
corresponding header.  But the ellipsis needs to be displayed one
character before the invisible text, so that it can appear on the same
line as the header.

Currently, the mechanism for displaying the ellipsis can only specify
*whether* to display an ellipsis.  I would like for it to be able to
specify *where* to display the ellipsis.

Now I'll be gone for a few days.  I should be back online to continue
this discussion on Monday.

Thank you,
--John

Re: Outline mode

[Davis Herring]

> No problem.  At "** Subheading, with elided body...\n" the newline
> after the ellipsis is the newline character just before the next
> subheading.  Users should definitely not be prevented from placing
> point at this character, because it is an ordinary visible character,
> and people may have any number of reasons for wanting to put point
> there (maybe they just want to `describe-text-properties' for some
> reason).  Thus, the movement commands are not the problem.

There's nothing preventing them from going there; with the "new" C-e they
just do C-n C-b to go to that (visible) newline.  With the
front-advance/rear-advance overlays, typing before that last newline will
add to the (invisible) body invisibly, as it should.

> However, it would be preferable, at least to me, to have that newline
> be invisible, and the newline immediately after the header to be
> visible, so that when I go to the end of that heading line, by
> whatever method, point is truly *on* the heading line.  Not having to
> arrow to the left saves me both keystrokes and cogitation.  The reason
> emacs cannot do this right now, is that if you hid that newline, and
> displayed the newline after the header instead, your outline would
> look like this:

If (with all my proposals) you go to the end of the header (via C-e or
whatever else that doesn't put you -past- the invisible newline that ends
it), you are then truly on the header and can edit however you like. 
Pressing C-b once would put you before the last normal character in the
heading (the 'y' of "body" in the example), and self-inserting would add
visible characters immediately after that character.  So (unless you do
want to insert in the middle of the header) no arrowing is required, and
no text is invisible that shouldn't be.

> In that case, you could put point at the end of your subheading, and
> edit with no funny surprises.  Derived modes would also see that you
> were in fact on a header-line (this problem is illustrated by
> org-cycle in org-mode, which can't cycle if point is to the right of
> the ellipsis).  But of course that outline looks silly.  We expect the
> ellipsis to appear on the header line.

I know nothing about org-mode, but again, there are no funny surprises,
aside from the bit where the cursor is rendered after the ellipsis. 
You're still "conceptually" in front of the ellipsis, in that inserted
text appears in front of it and one C-b moves you away from the ellipsis
entirely.  And I think that derived modes should be able to tell (unless
they're being too clever) that you're on the header: you are after all
before the header's newline.

> Currently, the mechanism for displaying the ellipsis can only specify
> *whether* to display an ellipsis.  I would like for it to be able to
> specify *where* to display the ellipsis.

Part of the reason I am attempting to prove the utility of the
C-e/advancing-overlay solution is that I fear such a feature would be
prohibitively expensive/complex.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Outline mode

[John J Foerch]

"Davis Herring" <herring@lanl.gov> writes:
>
> There's nothing preventing them from going there; with the "new" C-e they
> just do C-n C-b to go to that (visible) newline.  With the
> front-advance/rear-advance overlays, typing before that last newline will
> add to the (invisible) body invisibly, as it should.
>
> If (with all my proposals) you go to the end of the header (via C-e or
> whatever else that doesn't put you -past- the invisible newline that ends
> it), you are then truly on the header and can edit however you like. 
> Pressing C-b once would put you before the last normal character in the
> heading (the 'y' of "body" in the example), and self-inserting would add
> visible characters immediately after that character.  So (unless you do
> want to insert in the middle of the header) no arrowing is required, and
> no text is invisible that shouldn't be.
>
> I know nothing about org-mode, but again, there are no funny surprises,
> aside from the bit where the cursor is rendered after the ellipsis. 
> You're still "conceptually" in front of the ellipsis, in that inserted
> text appears in front of it and one C-b moves you away from the ellipsis
> entirely.  And I think that derived modes should be able to tell (unless
> they're being too clever) that you're on the header: you are after all
> before the header's newline.
>
> Part of the reason I am attempting to prove the utility of the
> C-e/advancing-overlay solution is that I fear such a feature would be
> prohibitively expensive/complex.
>
> Davis
>

Hi Davis,

Making the overlay rear-advance and front-advance sounds like a good
thing to do because that will solve some of the problem of the
inconsistency of inserting characters at the end of the header.

I still would not change any movement commands though.  If I came
across a situation where I could move point to some character by
moving backwards, but not forward, I would find that to be very
strange and would report it as a bug.  I would rather leave the quirk
in outline-mode and have some hope that I or someone else would figure
out how to add the feature to the ellipsis mechanism that I described.
Also, recall that I did implement a separate ellipsis mechanism in
elisp in the patch I posted, and I'm happy to keep using that until
the ellipsis code in emacs' C code can provide the behavior.

--John

Re: Outline mode

[Richard Stallman]

    Outline-mode has a problem that I would like to fix.  To see the
    problem, hide an entry (C-c C-c) in an outline-mode buffer, and put
    point at the end of the heading with C-e.  Point will then be located
    to the right of the ellipsis, and as far as emacs knows, point is on
    the last line of the hidden entry.  Typing characters or hitting
    backspace, and many other commands will affect the last line of the
    entry.

This is true, and it is consistent.  If you type C-e on the heading
and move past the ellipsis, you go just before the newline at the end
of the entry.  If you insert text there, it appears to be, and is,
located before that newline.

    When an entry is collapsed in outline-mode, what actually gets marked
    invisible is everything from the newline of the heading to the
    character before the final newline of the entry.  It would make more
    sense, if the newline of the heading were left visible, and the final
    newline of the entry were hidden.

I think the reason for this is that the newline that is displayed
appears to be right before the next entry.  If the newline character
that corresponds to is NOT the one right before the next entry,
you get strange results.