From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Kurn Newsgroups: gmane.emacs.bugs Subject: bug#10072: 23.3; invisible text Date: Sun, 20 Nov 2011 02:24:59 -0800 Message-ID: <20111120102459.GB12774@sfu.ca> References: <20111118191436.GA21091@sfu.ca> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1321784765 17179 80.91.229.12 (20 Nov 2011 10:26:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 20 Nov 2011 10:26:05 +0000 (UTC) Cc: 10072@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 20 11:26: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 1RS4b2-0006vD-Hw for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2011 11:26:00 +0100 Original-Received: from localhost ([::1]:39298 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RS4b1-0007ty-MR for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2011 05:25:59 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:48052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RS4ay-0007ti-7z for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 05:25:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RS4ax-0008Sf-7U for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 05:25:56 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:56852) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RS4ax-0008SZ-2N for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 05:25:55 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RS4c2-0005Ei-4r for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 05:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrew Kurn Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2011 10:27: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.132178477320062 (code B ref 10072); Sun, 20 Nov 2011 10:27:02 +0000 Original-Received: (at 10072) by debbugs.gnu.org; 20 Nov 2011 10:26:13 +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 1RS4bF-0005DW-4K for submit@debbugs.gnu.org; Sun, 20 Nov 2011 05:26:13 -0500 Original-Received: from pobox.sfu.ca ([142.58.101.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RS4bB-0005DL-7S for 10072@debbugs.gnu.org; Sun, 20 Nov 2011 05:26:10 -0500 Original-Received: from fraser.sfu.ca (fraser.sfu.ca [142.58.101.25]) by pobox.sfu.ca (8.13.6/8.13.5/SFU-6.0G) with ESMTP id pAKAOxIg011968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 20 Nov 2011 02:25:00 -0800 (PST) Original-Received: (from kurn@localhost) by fraser.sfu.ca (8.13.8+Sun/8.14.3/SFU-6.0C) id pAKAOxvW002792; Sun, 20 Nov 2011 02:24:59 -0800 (PST) Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sun, 20 Nov 2011 05:27: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:54087 Archived-At: 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