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 12:10:26 -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> <83poul2ob9.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1458749485 23880 80.91.229.3 (23 Mar 2016 16:11:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 16:11:25 +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 17:11:13 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 1ailNI-0003dU-JR for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 17:11:12 +0100 Original-Received: from localhost ([::1]:44857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailNH-0001Ty-Kp for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 12:11:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55889) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailND-0001Sm-Hp for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 12:11:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ailN8-00063u-Hv for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 12:11:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailN8-00063k-FP for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 12:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ailN8-00039T-4C for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 12:11:02 -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 16:11:02 +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.145874943612083 (code B ref 19200); Wed, 23 Mar 2016 16:11:02 +0000 Original-Received: (at 19200) by debbugs.gnu.org; 23 Mar 2016 16:10:36 +0000 Original-Received: from localhost ([127.0.0.1]:34627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailMh-00038p-Uu for submit@debbugs.gnu.org; Wed, 23 Mar 2016 12:10:36 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:57207) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailMg-00038h-6U for 19200@debbugs.gnu.org; Wed, 23 Mar 2016 12:10:34 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id u2NGAx7O008030; Wed, 23 Mar 2016 12:10:59 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 5EBDF661AA; Wed, 23 Mar 2016 12:10:26 -0400 (EDT) In-Reply-To: <83poul2ob9.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 23 Mar 2016 17:42:34 +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 <4563> : streams <1607624> : uri <2172844> 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:115397 Archived-At: > But we display characters, not positions. And the cursor is displayed > "on" some character as well. Yes. And from that point of view, there's no difference whether point is at position 3, 4, or 5: the display will be the same. So the choice of whether to put point at 3, 4, or 5 can't be just based on "what it looks like" but on what happens when the user performs an operation. And "The Right Thing" will then depend on the operation, and the reason why the text was made invisible. Which is why the chosen position needs to be controllable (the fact that it's controlled by stickiness is somewhat arbitrary in this respect). The choice of using stickiness is based on the idea that an important operation is insertion, in which case it's important to make sure that when the user moves around and edits a buffer that has invisible text, she doesn't end up inserting text that's invisible (and hence get the impression that the insertion somehow didn't even happen). > 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. I still don't see any relationship with point-adjustment. >> > 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? I don't see how that relates. Point-adjustment has to work regardless of which command was used, and point can end up at position 4 or 5 rather than position 3 for all kinds of reasons unrelated to invisibility, so if vertical-motion goes to position 5, it's really (or at least should be) a non-issue for point-adjustment. >> 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? No: the get-char-property-and-overlay calls will only determine the boundaries of the invisible text (i.e. they should find that the invisible chunk goes between 3 and 5). After that, adjust_point_for_property should start by moving point to position 3 (because last_pt should be < 3). And after that it should use Fget_pos_property to decide whether to stay at position 3 or to move to position 5, and in this case it should choose to stay at position 3. So someone needs to step through the code and figure out why this doesn't happen. E.g. maybe it doesn't happen because adjust_point_for_property is not called at all. Stefan