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.