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: Mon, 21 Nov 2011 03:37:33 -0800 Message-ID: <20111121113733.GB11214@sfu.ca> References: <20111118191436.GA21091@sfu.ca> <20111120102459.GB12774@sfu.ca> <20111121000321.GA19808@sfu.ca> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1321875482 8921 80.91.229.12 (21 Nov 2011 11:38:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 Nov 2011 11:38:02 +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 Mon Nov 21 12:37:58 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 1RSSCC-0007tE-U7 for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Nov 2011 12:37:57 +0100 Original-Received: from localhost ([::1]:54376 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSSCC-0004tj-4y for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Nov 2011 06:37:56 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:50560) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSSC7-0004sO-LU for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2011 06:37:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSSC4-0003ci-QP for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2011 06:37:51 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58653) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSSC4-0003ce-Ol for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2011 06:37:48 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RSSDF-0001Tv-P8 for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2011 06:39:01 -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: Mon, 21 Nov 2011 11:39:01 +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.13218755325680 (code B ref 10072); Mon, 21 Nov 2011 11:39:01 +0000 Original-Received: (at 10072) by debbugs.gnu.org; 21 Nov 2011 11:38:52 +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 1RSSD6-0001TZ-Ai for submit@debbugs.gnu.org; Mon, 21 Nov 2011 06:38:52 -0500 Original-Received: from pobox.sfu.ca ([142.58.101.28]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSSD3-0001TR-In for 10072@debbugs.gnu.org; Mon, 21 Nov 2011 06:38:50 -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 pALBbY1Y014585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 21 Nov 2011 03:37:35 -0800 (PST) Original-Received: (from kurn@localhost) by fraser.sfu.ca (8.13.8+Sun/8.14.3/SFU-6.0C) id pALBbYcW029551; Mon, 21 Nov 2011 03:37:34 -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: Mon, 21 Nov 2011 06:39:01 -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:54119 Archived-At: On Sun 20 Nov 2011 21:27 -0500, Stefan Monnier wrote: > > > Sorry, but I didn't receive this latest version. Could you re-send it? > > Sorry, it's appended this time. > [. . .] > > > I suspect that the philosophy of the command-loop-move-point > > thingy is to move point so that invisible text will not be > > inserted in /any/ case. > > No: doing it reliably is fiendishly difficult and in general cannot be > done without breaking some code somewhere. So instead the code does > a best effort which covers 99% of the cases. It's fundamentally > very DWIMish. > Ah. I didn't know that. I'd thought that the next-insert-must-not- inherit-invisible test could be applied until it returned true. [. . .] > I tend to consider Emacs as a great big pile of bugs. It very much > follows a pragmatic "don't worry too much about corner cases" (some > people might call it "worse is better"), so documenting all bugs would > be a daunting task. You can see the bug-tracker as a way to document > the known bugs. This is where I have a benefit from not being a regular reader of this mailing list: I consider Emacs to be very well debugged and the documentation to be astonishingly literate and complete -- perhaps the best of any program ever written. [. . .] > > I'd like to see a pre-redisplay-functions hook added to Emacs for > various reasons (e.g., for reveal-mode, as well as to move the > region-highlighting code to Elisp), and such a hook might possibly allow > a more reliable implementation of this feature, but don't hold > your breath. > Interesting. > > Anyhow, I'm pretty happy with my improved understanding, so I'm > > grateful for your help. Are you a volunteer? > > Yes, like all the other Emacs developers. [. . .] Regarding the text below, I think it serves to express the situation well. It makes it clear that the situation is not precisely described but is a compromise of sereral factors and, therefore, not to be strictly relied upon. And, of course, it describes things in more detail than the previous version, so an improvement. My thanks for all your work. Andrew ---------- > > > === modified file 'doc/lispref/display.texi' > --- a/doc/lispref/display.texi 2011-11-20 02:29:42 +0000 > +++ b/doc/lispref/display.texi 2011-11-20 20:21:22 +0000 > @@ -870,15 +870,21 @@ > 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 or at the boundary of invisible > +text, the main editing loop moves point to one of the two ends of the invisible > +text. Which end to move to is chosen based on the following factors: make sure > +that the overall movement of the command is still in the same direction, and > +prefer a position where an inserted char would not inherit the @code{invisible} > +property. Additionally, if the text is not replaced by an ellipsis and the > +command only moved within the invisible text, then point is moved one extra > +character so as to try and reflect the command's movement by a visible movement > +of the cursor. > + > + Thus, if the command moved point back to 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. > > Incremental search can make invisible overlays visible temporarily > and/or permanently when a match includes invisible text. To enable