From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#19200: Point adjustemnt moves *into* invisible text Date: Wed, 23 Mar 2016 17:42:34 +0200 Message-ID: <83poul2ob9.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458747871 29242 80.91.229.3 (23 Mar 2016 15:44:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 15:44:31 +0000 (UTC) Cc: michael_heerdegen@web.de, jonas@bernoul.li, 19200@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 23 16:44:14 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 1aikxB-0001jJ-FR for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 16:44:13 +0100 Original-Received: from localhost ([::1]:44605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aikx7-0005iZ-LU for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 11:44:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aikx3-0005iJ-4g for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:44:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aikwz-0006Zw-RQ for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:44:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aikwz-0006Zs-OO for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:44:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1aikwz-0002Ry-Jp for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Mar 2016 15:44: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.14587477929357 (code B ref 19200); Wed, 23 Mar 2016 15:44:01 +0000 Original-Received: (at 19200) by debbugs.gnu.org; 23 Mar 2016 15:43:12 +0000 Original-Received: from localhost ([127.0.0.1]:34597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aikwB-0002Qr-RD for submit@debbugs.gnu.org; Wed, 23 Mar 2016 11:43:12 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56754) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1aikw9-0002Qe-Ky for 19200@debbugs.gnu.org; Wed, 23 Mar 2016 11:43:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aikw1-0006Ql-7q for 19200@debbugs.gnu.org; Wed, 23 Mar 2016 11:43:04 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aikvs-0006Py-0i; Wed, 23 Mar 2016 11:42:52 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1874 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aikvr-0006KR-95; Wed, 23 Mar 2016 11:42:51 -0400 In-reply-to: (message from Stefan Monnier on Wed, 23 Mar 2016 11:32:29 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:115391 Archived-At: > From: Stefan Monnier > Cc: 19200@debbugs.gnu.org, michael_heerdegen@web.de, jonas@bernoul.li > Date: Wed, 23 Mar 2016 11:32:29 -0400 > > >> 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. But we display characters, not positions. And the cursor is displayed "on" some character as well. > > 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. Thank you, I don't think I forgot that. And it isn't important what I remember, because above I was talking about what the display code does: it examines properties of characters using the likes of get-char-property, and behaves accordingly. > > (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. That is not visible until you insert a character. By contrast, the characters and the cursor are visible at all times. > > 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. Read the code: it's all over the place. Why do you think vertical-motion ends up at position 5 in the test case you presented in this bug report? > 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. OK, then I don't see what can be done here. > 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. Didn't I do that? Doesn't the fact that the relevant code calls get-char-property-and-overlay explain what happens?