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 21:21:09 -0400 Message-ID: References: <83bpe3xqjj.fsf@gnu.org> <83ljd6w9p1.fsf@gnu.org> <837hopwvgl.fsf@gnu.org> <836349wo57.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 1270257688 4127 80.91.229.12 (3 Apr 2010 01:21:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 3 Apr 2010 01:21:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 03 03:21:24 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 1Nxs39-0007cF-DO for ged-emacs-devel@m.gmane.org; Sat, 03 Apr 2010 03:21:23 +0200 Original-Received: from localhost ([127.0.0.1]:47201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nxs38-0002pC-Ob for ged-emacs-devel@m.gmane.org; Fri, 02 Apr 2010 21:21:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nxs33-0002o0-11 for emacs-devel@gnu.org; Fri, 02 Apr 2010 21:21:17 -0400 Original-Received: from [140.186.70.92] (port=51070 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nxs31-0002nr-DZ for emacs-devel@gnu.org; Fri, 02 Apr 2010 21:21:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nxs30-0000Fh-03 for emacs-devel@gnu.org; Fri, 02 Apr 2010 21:21:15 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:39358 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nxs2x-0000Ep-44; Fri, 02 Apr 2010 21:21:11 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANo0tktFpZE8/2dsb2JhbACbSnKzZ4UFBIsn X-IronPort-AV: E=Sophos;i="4.51,355,1267419600"; d="scan'208";a="60140969" Original-Received: from 69-165-145-60.dsl.teksavvy.com (HELO ceviche.home) ([69.165.145.60]) by ironport2-out.pppoe.ca with ESMTP; 02 Apr 2010 21:21:10 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0442D660BF; Fri, 2 Apr 2010 21:21:10 -0400 (EDT) In-Reply-To: <836349wo57.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 03 Apr 2010 00:16:52 +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:123089 Archived-At: >> > The minibuffer completion use-case is different: there, we have no >> > text that comes from a buffer beyond the place where the cursor is >> > displayed. IOW, there're no glyphs to the right of the cursor that >> > came from the minibuffer. So there are no buffer positions that >> > "compete" for the cursor position, only the overlay with the >> > completion message. >> I can imagine using the same kind of message for in-buffer completion. > Then you need to use the "integer as `cursor' property value" > feature. I.e., don't just set the property's value non-nil, set it to > the integer number that specifies how many buffer positions are > ``covered'' by that cursor positions. That's what CUA Mode does in > cua-rect.el. Integer property values do override the "exact match for > point always wins" strategy. Yes, that sounds OK. But note that (except for when the after-string is at EOB) there's basically always a "exact match for point", so that basically means that the use of a value t for the `cursor' property will simply not work any more and might just be dropped. >> The position is not enough because we need to find the actual overlay >> where it came from and there can be several overlays at that buffer >> position. > Right, but we have the string, so we could look for the overlay that > specifies the same string. Yes, we could, tho of course the same string might be placed on several overlays at the same buffer position, and we have to check whether it's on a before-string or an after-string or ... I.e. it's workable but it'd probably be ugly. >> But I do not object at all to your general argument "I think this kind >> of problems should be fixed, not worked around with the `cursor' >> property". I seem to remember making the same observation, then jumping >> to the C code, and finally deciding "too hard for me, I'll live with the >> workaround for now". So if you can fix it, that would be great. > I'd need to see the requirements first. Just that it places the cursor on the "before" or "after" position of (after|before|display)-strings depending on the stickiness/insertion-type of the corresponding overlay/text-property. Stefan