From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#10072: 23.3; invisible text Date: Sat, 19 Nov 2011 23:57:13 -0500 Message-ID: References: <20111118191436.GA21091@sfu.ca> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1321765085 14389 80.91.229.12 (20 Nov 2011 04:58:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 20 Nov 2011 04:58:05 +0000 (UTC) Cc: 10072@debbugs.gnu.org To: Andrew Kurn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 20 05:58:01 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RRzTd-0007rT-0z for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2011 05:58:01 +0100 Original-Received: from localhost ([::1]:40624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRzTc-00009G-NW for geb-bug-gnu-emacs@m.gmane.org; Sat, 19 Nov 2011 23:58:00 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:53075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRzTZ-00009B-My for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2011 23:57:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RRzTY-0008Of-JV for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2011 23:57:57 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRzTY-0008Ob-GZ for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2011 23:57:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RRzUc-00063X-4H for bug-gnu-emacs@gnu.org; Sat, 19 Nov 2011 23:59:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2011 04:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10072 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10072-submit@debbugs.gnu.org id=B10072.132176510323233 (code B ref 10072); Sun, 20 Nov 2011 04:59:02 +0000 Original-Received: (at 10072) by debbugs.gnu.org; 20 Nov 2011 04:58:23 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RRzTy-00062f-PG for submit@debbugs.gnu.org; Sat, 19 Nov 2011 23:58:23 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RRzTw-00062Y-Cf for 10072@debbugs.gnu.org; Sat, 19 Nov 2011 23:58:21 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAECIyE5FpZyx/2dsb2JhbABDqBSCKYEGgXIBAQQBViMFCws0EhQYDSSIFrUeihcEiBqZeoRL X-IronPort-AV: E=Sophos;i="4.69,541,1315195200"; d="scan'208";a="148661789" Original-Received: from 69-165-156-177.dsl.teksavvy.com (HELO pastel.home) ([69.165.156.177]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 19 Nov 2011 23:57:13 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 57D1859372; Sat, 19 Nov 2011 23:57:13 -0500 (EST) In-Reply-To: <20111118191436.GA21091@sfu.ca> (Andrew Kurn's message of "Fri, 18 Nov 2011 11:14:36 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 19 Nov 2011 23:59:02 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:54086 Archived-At: > 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