From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Cursor positioning with `after-string' overlays Date: Fri, 02 Apr 2010 14:17:31 -0400 Message-ID: References: <83bpe3xqjj.fsf@gnu.org> <83ljd6w9p1.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1270232270 28679 80.91.229.12 (2 Apr 2010 18:17:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 2 Apr 2010 18:17:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 02 20:17:45 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 1NxlRA-0007Ko-Eb for ged-emacs-devel@m.gmane.org; Fri, 02 Apr 2010 20:17:44 +0200 Original-Received: from localhost ([127.0.0.1]:38739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxlR9-0001RT-Pe for ged-emacs-devel@m.gmane.org; Fri, 02 Apr 2010 14:17:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NxlR4-0001Pt-W8 for emacs-devel@gnu.org; Fri, 02 Apr 2010 14:17:39 -0400 Original-Received: from [140.186.70.92] (port=46355 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NxlR3-0001Nn-N6 for emacs-devel@gnu.org; Fri, 02 Apr 2010 14:17:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NxlR2-0000AI-Fz for emacs-devel@gnu.org; Fri, 02 Apr 2010 14:17:37 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:19335 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NxlQy-00009d-OA; Fri, 02 Apr 2010 14:17:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD7RtUtFpZE8/2dsb2JhbACbSHK0O4UFBIsn X-IronPort-AV: E=Sophos;i="4.51,354,1267419600"; d="scan'208";a="60129386" Original-Received: from 69-165-145-60.dsl.teksavvy.com (HELO pastel.home) ([69.165.145.60]) by ironport2-out.pppoe.ca with ESMTP; 02 Apr 2010 14:17:31 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 8CABC85F0; Fri, 2 Apr 2010 14:17:31 -0400 (EDT) In-Reply-To: <83ljd6w9p1.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Apr 2010 11:16:42 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:123073 Archived-At: >>>>> "Eli" == Eli Zaretskii writes: >> 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. Try: (let ((pos (goto-char (point-max)))) (insert "foobar") (overlay-put (make-overlay (+ pos 2) (+ pos 3) nil nil t) 'after-string (propertize "-" 'cursor t))) (i.e. I added "nil nil t" to the call to make-overlay). > In any case, do you really think that being unable to put the cursor > on `b' (with the old code) is correct behavior? No. The old behavior had its share of problems as well. >> 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 hope the sample code above makes it more clear (I'm talking about the marker-insertion-type of the underlying/implicit markers used as end points of the overlay). For text-properties it's called stickiness. >> 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. Exactly, yes. > 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? See my sample code above again or think of the minibuffer messages during completion: depending on the particular case, the intention of the text inserted via an after-string may be to appear "before" or "after" the cursor. >> 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. IIRC last time I looked at it, it would require a significant restructuring to get the needed information. I can't remember the details, but I seem to remember that one of the problem is that at the moment we handle the cursor position all we know is "we're displaying string S", so we know the text displayed comes from a string rather than from a buffer, but we don't know where that string comes from: we've forgotten all about whether it's from a display property, or an overlay, so we can't check the corresponding stickiness/insertion-type. Stefan