From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Cursor positioning with `after-string' overlays Date: Fri, 02 Apr 2010 11:16:42 +0300 Message-ID: <83ljd6w9p1.fsf@gnu.org> References: <83bpe3xqjj.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1270196606 12898 80.91.229.12 (2 Apr 2010 08:23:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Apr 2010 08:23:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 02 10:23:22 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nxc9x-0001Ty-Sb for ged-emacs-devel@m.gmane.org; Fri, 02 Apr 2010 10:23:22 +0200 Original-Received: from localhost ([127.0.0.1]:42497 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nxc9x-0002bw-0q for ged-emacs-devel@m.gmane.org; Fri, 02 Apr 2010 04:23:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nxc4A-00089P-HR for emacs-devel@gnu.org; Fri, 02 Apr 2010 04:17:22 -0400 Original-Received: from [140.186.70.92] (port=36537 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nxc46-00088G-Ux for emacs-devel@gnu.org; Fri, 02 Apr 2010 04:17:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nxc43-0003au-TO for emacs-devel@gnu.org; Fri, 02 Apr 2010 04:17:18 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58577) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nxc43-0003aX-Lz for emacs-devel@gnu.org; Fri, 02 Apr 2010 04:17:15 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L0800000PN7EG00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 02 Apr 2010 11:16:41 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.124.92.42]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L0800LOQPNS4H50@a-mtaout22.012.net.il>; Fri, 02 Apr 2010 11:16:41 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123055 Archived-At: > From: Stefan Monnier > Date: Thu, 01 Apr 2010 18:06:26 -0400 > Cc: emacs-devel@gnu.org > > > found. IOW, exact match wins over all other considerations. Since > > C-f from the second `o' moves point to buffer position to which `b' > > corresponds exactly, that is where the trunk version puts the cursor. > > But depending on the insertion-type of the end marker of your overlay, > text inserted "at point" will be inserted (visually) between the o and > the - rather than between the - and the b, so while this choice would > sometimes be correct, it's sometimes incorrect. Sorry, I don't understand the specific situation. In my example, when the cursor is on `b', insertion happens between `-' and `b', which is visually correct. Can you modify my example to create the situation you are describing? Then I could try to reason about it and perhaps modify the code if necessary. In any case, do you really think that being unable to put the cursor on `b' (with the old code) is correct behavior? The `after-string' does not replace `b' on the screen and doesn't cover its position, so this behavior looks like a subtle bug, since `b' comes from the buffer. > That's why we have the > `cursor' property (although admittedly, for this particular use, the > insertion-type of the marker should already provide the needed info). What do you mean by ``the insertion-type of the marker''? I've seen your comments in minibuffer.el about something similar, so perhaps now is the time to add whatever features you thought were absent. > One use case is when you simply want to control where the cursor is > displayed on a piece of text that's not in the buffer (typically an > after-string). In such a case, without any extra information, it would > not be incorrect to place the cursor before the after-string, or after > the after-string or anywhere in between. So the `cursor' property > allows to specify the intended behavior (e.g. the after-string has the > form "()" and you want the cursor to appear in between the two parens). This may make sense when the string is displayed _instead_ of some portion of the buffer, or perhaps when we have a single buffer position that uses up several columns on display, like in Kim's example with a TAB in Cua Mode. But if you type C-f, which moves point to the next buffer position, and the glyph produced from that buffer position is displayed on the screen, how can it be TRT not to place the cursor on that glyph? > The other use case is when the cursor positioning code gets it wrong > because it works at too low a level (typically the after-string or > similar thingy is on an overlay with carefully chosen stickiness which > should make it clear whether the cursor should come before or after the > string, but the cursor positioning code only gets to see a "flattened" > representation of the text, so it can't know the stickiness property). I think this kind of problems should be fixed, not worked around with the `cursor' property. The cursor-positioning code does not work only on glyphs, it does search the buffer for `display' properties and overlays, so whatever information is available in the buffer, the cursor-positioning code can get at it.