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 15:30:13 -0500 Message-ID: References: <20111118191436.GA21091@sfu.ca> <20111120102459.GB12774@sfu.ca> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1321821063 12984 80.91.229.12 (20 Nov 2011 20:31:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 20 Nov 2011 20:31: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 Sun Nov 20 21:30:57 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 1RSE2S-0004w8-QE for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2011 21:30:56 +0100 Original-Received: from localhost ([::1]:42254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSE2S-0004eb-0k for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2011 15:30:56 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:34586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSE2P-0004eL-J1 for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 15:30:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RSE2O-0006Ky-8u for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 15:30:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RSE2O-0006Ku-65 for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 15:30:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1RSE3V-0004pS-Q0 for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2011 15:32:01 -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 20:32: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.132182108918520 (code B ref 10072); Sun, 20 Nov 2011 20:32:01 +0000 Original-Received: (at 10072) by debbugs.gnu.org; 20 Nov 2011 20:31:29 +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 1RSE2x-0004od-Vz for submit@debbugs.gnu.org; Sun, 20 Nov 2011 15:31:29 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RSE2v-0004oT-Cx for 10072@debbugs.gnu.org; Sun, 20 Nov 2011 15:31:26 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABhiyU5FpZyx/2dsb2JhbABCqj6BBoFyAQEEAVYjBQsLNBIUGA0kiBa1SYoXBIgamXqESw X-IronPort-AV: E=Sophos;i="4.69,544,1315195200"; d="scan'208";a="148730573" Original-Received: from 69-165-156-177.dsl.teksavvy.com (HELO ceviche.home) ([69.165.156.177]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 20 Nov 2011 15:30:14 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id B98E0661B5; Sun, 20 Nov 2011 15:30:13 -0500 (EST) In-Reply-To: <20111120102459.GB12774@sfu.ca> (Andrew Kurn's message of "Sun, 20 Nov 2011 02:24:59 -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 15:32: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:54099 Archived-At: > 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. > --------- Thanks. I installed the text below instead (which is closer to what really happens). > 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 use of a block cursor that covers the "next visible char" indeed tends to make people assume that point is right before that visible char, but if you use a different cursor this is much less true. In any case the driving factor is to try and avoid the case where self-insert-command inserts invisible text, which is also very confusing. Another advantage of the current behavior is that it lets the author choose where to place point, by setting stickiness appropriately, so you can get Emacs to indeed place the cursor right in front of the next visible char. >> 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. Fundamentally it's a bug, and I generally don't like to document bugs. Stefan