bug#10072: 23.3; invisible text

[Andrew Kurn]

On Sat 19 Nov 2011 23:57 -0500, Stefan Monnier wrote:
> 
> > I'm seeing a collection of funny behavior around invisible text.
> > Here are some examples.
> 
> > emacs -Q -nw
> > (setq s "XXX,")
> > (put-text-property 0 3 'invisible t s)
> > (setq s (concat s s s))
> > (insert s)
> 
> > If I move the cursor around, it will stop before an invisible X.
> 
> I'm not sure what you mean by "stop".
> 
> > This is not the advertised behavior.  (I discover its position by
> > using Ctl-X =)
> 
> >> From sec. 38.6 of E-Lisp:
> > ---
> >    However, if a command ends with point inside or immediately before
> > invisible text, the main editing loop moves point further forward or
> 
> Oh, you mean that point stays "immediately before" the "X"?
> You're right: the Elisp manual is wrong (because incomplete) here.
> Does the patch below clears things up?
> 

Actually, no.  The new text contradicts itself.  The example
included contradicts the definition, which is hard to read
because the definition is interrupted by the example.

Let me propose this wording:
-----------
  However, if a command ends with point inside invisible text, the main editing
loop moves point further forward or further backward (in the same direction
that the command already moved it) until that condition is no longer true.
The positions immediately before and immediately after invisible text are
considered inside the invisible text if a char inserted at that position would
inherit the @code{invisible} property.


Thus, if the command moved point back into an invisible range
(with the usual stickiness), Emacs moves
point back to the beginning of that range.
If the command moved point forward into an invisible range, Emacs moves point
forward to the first visible character that follows the invisible text
and then forward one more character.
---------

That is indeed the behavior I see.

As an opinion, I add that it would be more intuitive if it worked
differently -- the way described in the original example -- but
I can live with this once it is clearly explained.  (The problem
is, of course, that ^X= should always name a visible character,
and the one that the cursor is over.)

[. . .]

> 
> The code that moves point out of invisible chunks of text does not
> always work, indeed, because it is only applied to the current
> buffer (or maybe the selected-window?) after a command.
> 
> 

Yes, I see.  This might need clarification in the text also.


> 
> === modified file 'doc/lispref/display.texi'
> --- doc/lispref/display.texi  2011-11-20 02:29:42 +0000
> +++ doc/lispref/display.texi  2011-11-20 04:45:57 +0000
> @@ -870,15 +870,16 @@

[. . .]



So, now one must choose:  the intuitive behavior or the "sticky"
kind.  Please let me know your thoughts on this.

Andrew