From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Getting the click position in a string Date: Tue, 25 Apr 2006 16:55:28 +0200 Message-ID: <85vesxso0v.fsf@lola.goethe.zz> References: <85fyk2ugle.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1145977003 21734 80.91.229.2 (25 Apr 2006 14:56:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2006 14:56:43 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 25 16:56:42 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FYOxN-00082a-0a for ged-emacs-devel@m.gmane.org; Tue, 25 Apr 2006 16:56:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYOxM-0004Hh-0N for ged-emacs-devel@m.gmane.org; Tue, 25 Apr 2006 10:56:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYOx9-0004FC-B7 for emacs-devel@gnu.org; Tue, 25 Apr 2006 10:55:47 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYOx7-0004Cf-Hu for emacs-devel@gnu.org; Tue, 25 Apr 2006 10:55:46 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYOx7-0004Cb-Du for emacs-devel@gnu.org; Tue, 25 Apr 2006 10:55:45 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FYOzb-0003cz-4x for emacs-devel@gnu.org; Tue, 25 Apr 2006 10:58:19 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1FYOx4-00058k-Nd; Tue, 25 Apr 2006 10:55:43 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 373F51D1FFCD; Tue, 25 Apr 2006 16:55:28 +0200 (CEST) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: (Kim F. Storm's message of "Tue, 25 Apr 2006 16:36:44 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:53386 Archived-At: storm@cua.dk (Kim F. Storm) writes: > David Kastrup writes: > >> Hi, >> >> I am trying to fix mouse.el so that it can heed follow-link properties >> in display strings. But it does not appear that the mouse click info >> gives the requisite position information: there is posn-string, and >> there is posn-point, but it does not look like there is >> posn-string-pos or whatever else which would be able to pinpoint the >> actual position within a string that is used as a display property or >> before-string or after-string. > > It should be there -- > > posn-string should return a cons ("string" . POS) Uh, what? posn-string is a compiled Lisp function in `subr.el'. (posn-string POSITION) Return the string object of POSITION, or nil if a buffer position. POSITION should be a list of the form returned by the `event-start' and `event-end' functions. [back] I am afraid that the help string does not suggest that. "string object" is not really a well-known term in my book and amounts to a string in my naive connotations. It appears that indeed a cons is returned. Similarly for posn-object is a compiled Lisp function in `subr.el'. (posn-object POSITION) Return the object (image or string) of POSITION. POSITION should be a list of the form returned by the `event-start' and `event-end' functions. [back] I mean, how is one supposed to guess that "image or string" is actually going to be a cons? I am not sure that the name of those functions is well-chosen. But irrespective of that, the doc strings are less than helpful here. We need to do something about that. Personally, I'd have expected posn-object and posn-string to just return the image or string, and then have a separate posn-offset or posn-object-pos or so that will deliver the corresponding offset _if_ there is such a one. That would seem somewhat natural. Sorry for noticing this only now. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum