bug#10072: 23.3; invisible text

[Stefan Monnier]

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

Thanks.  I installed the text below instead (which is closer to what
really happens).

> 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 use of a block cursor that covers the "next visible char" indeed
tends to make people assume that point is right before that visible
char, but if you use a different cursor this is much less true.

In any case the driving factor is to try and avoid the case where
self-insert-command inserts invisible text, which is also
very confusing.  Another advantage of the current behavior is that it
lets the author choose where to place point, by setting
stickiness appropriately, so you can get Emacs to indeed place the
cursor right in front of the next visible char.

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

Fundamentally it's a bug, and I generally don't like to document bugs.


        Stefan