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#19200: Point adjustemnt moves *into* invisible text Date: Wed, 23 Mar 2016 11:32:29 -0400 Message-ID: References: <87mvpskb84.fsf@web.de> <87io0gbmpl.fsf@web.de> <87d1qnevco.fsf@web.de> <83h9fz65ze.fsf@gnu.org> <83r3f24gbk.fsf@gnu.org> <83egb24a5y.fsf@gnu.org> <83vb4d2pkt.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458747202 18273 80.91.229.3 (23 Mar 2016 15:33:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 15:33:22 +0000 (UTC) Cc: michael_heerdegen@web.de, jonas@bernoul.li, 19200@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 23 16:33:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aikmS-0002Dt-QW for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 16:33:08 +0100 Original-Received: from localhost ([::1]:44561 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aikmS-0000it-6j for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 11:33:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aikmP-0000iP-9A for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:33:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aikmM-0003HH-2A for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:33:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37463) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aikmL-0003H4-V3 for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:33:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aikmL-000296-Le for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Mar 2016 15:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19200 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 19200-submit@debbugs.gnu.org id=B19200.14587471598218 (code B ref 19200); Wed, 23 Mar 2016 15:33:01 +0000 Original-Received: (at 19200) by debbugs.gnu.org; 23 Mar 2016 15:32:39 +0000 Original-Received: from localhost ([127.0.0.1]:34590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aikly-00028U-Qa for submit@debbugs.gnu.org; Wed, 23 Mar 2016 11:32:39 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:33844) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aiklw-00028J-48 for 19200@debbugs.gnu.org; Wed, 23 Mar 2016 11:32:37 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id u2NFWTOx009114; Wed, 23 Mar 2016 11:32:30 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id C3ED5661AB; Wed, 23 Mar 2016 11:32:29 -0400 (EDT) In-Reply-To: <83vb4d2pkt.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 23 Mar 2016 17:15:14 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5619=0 X-NAI-Spam-Version: 2.3.0.9418 : core <5619> : inlines <4562> : streams <1607610> : uri <2172828> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:115390 Archived-At: >> No, you have it backwards: position 5 is invisible and position 3 is not. > So you are saying that we also have a display bug, in that what should > have been on the screen is "3" and not "5"? ;-) No: the character after position 3 is invisible, but the position 3 is not. Inversely, the character after position 5 is visible while the position is not. > You are talking about a different kind of "invisible", the kind that > is different from how the display engine, and any cursor-motion > commands that use its layout routines, interprets "invisible". No. You just have to remember that characters are between positions and positions are between characters, so the two can't be conflated. > (Personally, I think your notion of "invisible" is also confusing for > the user, in that it puts the cursor on a character whose position is > not the same as point. That's not my choice and that's not hard coded. It's the choice of the stickiness settings for that particular invisible property. It can be controlled by text property stickiness and overlay's marker's insertion types. E.g. if you use overlays to make the text invisible, then (by default) the position's invisibility is the same as the following character's (which is what you seem to like). For text-properties, by default it's the reverse (i.e. the position's visibility is the same as the *preceding* character). > The other notion of "invisible" also has its disadvantages, so it's > not easy to decide which one is "right", but at least it doesn't fight > an uphill battle against the display engine.) AFAIK there's no relevant interaction with the display engine. The only real problem is that people don't realize that the reality is more complex than what they expect. >> No, this bug is secondary. The main bug is that we end up at position >> 5 after C-n. > Since we don't know how to fix the main bug, would it be an > improvement to solve the secondary one? The secondary bug is pretty cosmetic and (at least in this case) is rather helpful, so I'm not sure it would be an improvement in itself. The issue of the main bug is not so much that we don't know how to fix it, but that noone has bothered to investigate it to try and figure out what is actually happening. Stefan