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: Sun, 20 Nov 2011 21:27:04 -0500 Message-ID: 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 X-Trace: dough.gmane.org 1321842483 8919 80.91.229.12 (21 Nov 2011 02:28:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 21 Nov 2011 02:28:03 +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 Mon Nov 21 03:27:56 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 1RSJbw-00037u-G1 for geb-bug-gnu-emacs@m.gmane.org; Mon, 21 Nov 2011 03:27:56 +0100 Original-Received: from localhost ([::1]:53398 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSJbv-0005k9-VS for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2011 21:27:55 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:33243) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSJbt-0005k4-3h for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 21:27:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSJbr-0004PK-Su for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 21:27:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSJbr-0004PD-NS for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 21:27:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RSJd0-0004dm-8N for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 21:29: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: Mon, 21 Nov 2011 02:29: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.132184250017781 (code B ref 10072); Mon, 21 Nov 2011 02:29:02 +0000 Original-Received: (at 10072) by debbugs.gnu.org; 21 Nov 2011 02:28:20 +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 1RSJcK-0004ck-AC for submit@debbugs.gnu.org; Sun, 20 Nov 2011 21:28:20 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSJcI-0004cc-1V for 10072@debbugs.gnu.org; Sun, 20 Nov 2011 21:28:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADm2yU5FxIAT/2dsb2JhbABDqBOCKoEGgXIBAQQBViMFCws0EhQYDSQxh2WzBooXBIgamXqESw X-IronPort-AV: E=Sophos;i="4.69,544,1315195200"; d="scan'208";a="148746488" Original-Received: from 69-196-128-19.dsl.teksavvy.com (HELO ceviche.home) ([69.196.128.19]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Nov 2011 21:27:04 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 2D920660D4; Sun, 20 Nov 2011 21:27:04 -0500 (EST) In-Reply-To: <20111121000321.GA19808@sfu.ca> (Andrew Kurn's message of "Sun, 20 Nov 2011 16:03:21 -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: Sun, 20 Nov 2011 21:29: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:54107 Archived-At: > Sorry, but I didn't receive this latest version. Could you re-send it? Sorry, it's appended this time. > Right this moment, I don't have access to the latest version > of Emacs, so I am not sure of the relevance of this remark: > However, I was experimenting with invisibility in overlays > and I found it was possible to insert invisible text. > 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. > So there's another possible bug. Probably, but maybe it's one of those cases where we can't win. >> Fundamentally it's a bug, and I generally don't like to document bugs. > On this point I disagree with you very strongly. It's much /more/ > important to document bugs than any other aspect of the code. I have > told several students this from time to time, and, like you, they > tend to resist the idea. 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. > I gather that there is no great push on to remedy this behavior, > so this bug may hang around for some time . . . Yes, I don't know of any effort to solve it, because the inconvenients tend to be rather minor compared to the effort it would take to make it work more reliably (some of those efforts would be spent figuring out what the hell Emacs should do in various corner cases). 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. > 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. > I guess that FSF doesn't have enough money to employ a staff of > programmers to deal with this sort of correspondence. Indeed. Stefan === 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