bug#10072: 23.3; invisible text

[Stefan Monnier]

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

> Also, this:
> (let ()
>   (with-current-buffer (get-buffer-create "B")
>     (goto-char 1)
>     (insert s)
>     (goto-char 1)
>     (re-search-forward ",X")
> )
> )

> will leave point at an invisible position, where it stays if
> you pop up a window on B.

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.

> I have one more bug, which I'm having trouble reproducing, where an
> /after-string/ of blanks attached to an overlay on invisible text
> displays fewer than requested.  If you know what this one is already
> you can save me some trouble.

That doesn't ring a bell, sorry.


        Stefan


=== 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 @@
 non-@code{nil} (the default), but only because they are explicitly
 programmed to do so.
 
-  However, if a command ends with point inside or immediately before
-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.  Thus, if the command
-moved point back into an invisible range, Emacs moves point back to
-the beginning of that range, and then back one more character.  If the
-command moved point forward into an invisible range, Emacs moves point
-forward up to the first visible character that follows the invisible
-text.
+  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.
+Thus, if the command moved point back into an invisible range, Emacs moves
+point back to the beginning of that range, and then back one more character.
+If the command moved point forward into an invisible range, Emacs moves point
+forward up to the first visible character that follows the invisible text.
+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.
 
   Incremental search can make invisible overlays visible temporarily
 and/or permanently when a match includes invisible text.  To enable