unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Andrew Kurn <kurn@sfu.ca>
Cc: 10072@debbugs.gnu.org
Subject: bug#10072: 23.3; invisible text
Date: Sat, 19 Nov 2011 23:57:13 -0500	[thread overview]
Message-ID: <jwv39djz9vk.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <20111118191436.GA21091@sfu.ca> (Andrew Kurn's message of "Fri, 18 Nov 2011 11:14:36 -0800")

> 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






  reply	other threads:[~2011-11-20  4:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-18 19:14 bug#10072: 23.3; invisible text Andrew Kurn
2011-11-20  4:57 ` Stefan Monnier [this message]
2011-11-20 10:24   ` Andrew Kurn
2011-11-20 20:30     ` Stefan Monnier
2011-11-21  0:03       ` Andrew Kurn
2011-11-21  0:27         ` Drew Adams
2011-11-21 11:12           ` Andrew Kurn
2011-11-21  2:27         ` Stefan Monnier
2011-11-21 11:37           ` Andrew Kurn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwv39djz9vk.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=10072@debbugs.gnu.org \
    --cc=kurn@sfu.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).