Getting the click position in a string

Getting the click position in a string

[David Kastrup]

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.

Consequently, one can't fetch the text property at the position of the
click in such a string.

Am I wrong here?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[Kim F. Storm]

David Kastrup <dak@gnu.org> 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)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Getting the click position in a string

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> 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

Re: Getting the click position in a string

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> I mean, how is one supposed to guess that "image or string" is
> actually going to be a cons?

RTFM :-)

 - Function: posn-string position
     Return the string object in POSITION, either `nil', or a cons cell
     `(STRING . STRING-POS)'.

 - Function: posn-object position
     Return the image or string object in POSITION, either `nil', an
     image `(image ...)', or a cons cell `(STRING . STRING-POS)'.

> 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.

Maybe, but there is already too many posn- functions :-)

>
> Sorry for noticing this only now.

Don't worry.  I will fix the doc strings.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Getting the click position in a string

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

David Kastrup <dak@gnu.org> 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.
>
> Consequently, one can't fetch the text property at the position of the
> click in such a string.
>
> Am I wrong here?

On another tangent, is this change ok?  For implementing follow-link,
I need to take a look at the follow-link binding in the keymap of a
click, not the binding of the click itself.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2081 bytes --]

*** help.el	25 Mar 2006 20:49:31 +0100	1.308
--- help.el	26 Apr 2006 10:08:16 +0200	
***************
*** 525,541 ****
  	  (princ string)))))
    nil)
  
! (defun string-key-binding (key)
!   "Value is the binding of KEY in a string.
! If KEY is an event on a string, and that string has a `local-map'
! or `keymap' property, return the binding of KEY in the string's keymap."
    (let* ((defn nil)
! 	 (start (when (vectorp key)
! 		  (if (memq (aref key 0)
  			    '(mode-line header-line left-margin right-margin))
! 		      (event-start (aref key 1))
! 		    (and (consp (aref key 0))
! 			 (event-start (aref key 0))))))
  	 (string-info (and (consp start) (nth 4 start))))
      (when string-info
        (let* ((string (car string-info))
--- 525,542 ----
  	  (princ string)))))
    nil)
  
! (defun string-key-binding (event &optional key)
!   "With some string EVENT, return the local binding of KEY.
! If EVENT is an event on a string, and that string has a `local-map'
! or `keymap' property, return the binding of KEY in the string's keymap.
! If KEY is not specified, it is taken from the event."
    (let* ((defn nil)
! 	 (start (when (vectorp event)
! 		  (if (memq (aref event 0)
  			    '(mode-line header-line left-margin right-margin))
! 		      (event-start (aref event 1))
! 		    (and (consp (aref event 0))
! 			 (event-start (aref event 0))))))
  	 (string-info (and (consp start) (nth 4 start))))
      (when string-info
        (let* ((string (car string-info))
***************
*** 544,550 ****
  			     (< pos (length string))
  			     (or (get-text-property pos 'local-map string)
  				 (get-text-property pos 'keymap string)))))
! 	(setq defn (and local-map (lookup-key local-map key)))))
      defn))
  
  (defun help-key-description (key untranslated)
--- 545,551 ----
  			     (< pos (length string))
  			     (or (get-text-property pos 'local-map string)
  				 (get-text-property pos 'keymap string)))))
! 	(setq defn (and local-map (lookup-key local-map (or key event))))))
      defn))
  
  (defun help-key-description (key untranslated)

[-- Attachment #3: Type: text/plain, Size: 340 bytes --]


Incidentally, this function looks faulty: it should search the keymap
_and_ the local-map property (in _that_ order) instead of searching at
most one of the two, even if that search would fail.

Apart from fixing it and adding an optional key argument, is help.el
the right place for it?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Getting the click position in a string

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>> Am I wrong here?

I think I answered that... (answer: yes)

>
> On another tangent, is this change ok?  For implementing follow-link,
> I need to take a look at the follow-link binding in the keymap of a
> click, not the binding of the click itself.

Looks ok to me.
> Incidentally, this function looks faulty: it should search the keymap
> _and_ the local-map property (in _that_ order) instead of searching at
> most one of the two, even if that search would fail.

I think the rationale is that one assumes that a user would only add
either a keymap or a local-map property -- but in any case, it should
look for the keymap property before the local-map property.

But it seems easy to fix it to DTRT.

> Apart from fixing it and adding an optional key argument, is help.el
> the right place for it?

For what?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Getting the click position in a string

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>>> Am I wrong here?
>
> I think I answered that... (answer: yes)
>
>>
>> On another tangent, is this change ok?  For implementing follow-link,
>> I need to take a look at the follow-link binding in the keymap of a
>> click, not the binding of the click itself.
>
> Looks ok to me.
>> Incidentally, this function looks faulty: it should search the keymap
>> _and_ the local-map property (in _that_ order) instead of searching at
>> most one of the two, even if that search would fail.
>
> I think the rationale is that one assumes that a user would only add
> either a keymap or a local-map property

But there are lots of maps between those two in the search order, so
there might be good reason to use both even in a single application.

> -- but in any case, it should look for the keymap property before
> the local-map property.
>
> But it seems easy to fix it to DTRT.

I will do a fix which looks in both keymaps.  Maybe there should be
something like posn-key-binding which looks through _all_ relevant
keymaps at the point of a click (which would include the various
buffer-local and global maps)?

How does this actually work in the normal event loop?

>> Apart from fixing it and adding an optional key argument, is help.el
>> the right place for it?
>
> For what?

For the function `string-key-binding'.  If I add an optional KEY
argument, this function becomes a "general-purpose" function used
outside of help.el (which is the point of the exercise), and putting
it there is probably counterintuitive.  It should probably be with
`posn-string' and similar, which are currently in subr.el.

It also appears that string-key-binding is not in the Elisp manual.
It might be worth grouping with the `posn-string' and similar
descriptions, too.

However, I'll fix it in help.el for now, check in that change, and
whether to move it can still be decided afterwards.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>>
>>> On another tangent, is this change ok?  For implementing follow-link,
>>> I need to take a look at the follow-link binding in the keymap of a
>>> click, not the binding of the click itself.
>>
>> Looks ok to me.
>
>> -- but in any case, it should look for the keymap property before
>> the local-map property.
>>
>> But it seems easy to fix it to DTRT.
>
> I will do a fix which looks in both keymaps.  Maybe there should be
> something like posn-key-binding which looks through _all_ relevant
> keymaps at the point of a click (which would include the various
> buffer-local and global maps)?

Well, here is the current patch.

But I increasingly feel that this is not the right way to go, the
whole function should get dissed out, and instead we should have
something like

(posn-key-binding event &optional accept-default remap key)

or something like that (maybe as a primitive C function), and the
event loop and help functions and so should consistently use that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 93 bytes --]

David Kastrup <dak@gnu.org> writes:

> Well, here is the current patch.

Uh, actually here.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2209 bytes --]

*** help.el	25 Mar 2006 20:49:31 +0100	1.308
--- help.el	26 Apr 2006 14:09:59 +0200	
***************
*** 525,550 ****
  	  (princ string)))))
    nil)
  
! (defun string-key-binding (key)
!   "Value is the binding of KEY in a string.
! If KEY is an event on a string, and that string has a `local-map'
! or `keymap' property, return the binding of KEY in the string's keymap."
    (let* ((defn nil)
! 	 (start (when (vectorp key)
! 		  (if (memq (aref key 0)
  			    '(mode-line header-line left-margin right-margin))
! 		      (event-start (aref key 1))
! 		    (and (consp (aref key 0))
! 			 (event-start (aref key 0))))))
  	 (string-info (and (consp start) (nth 4 start))))
      (when string-info
        (let* ((string (car string-info))
  	     (pos (cdr string-info))
! 	     (local-map (and (>= pos 0)
! 			     (< pos (length string))
! 			     (or (get-text-property pos 'local-map string)
! 				 (get-text-property pos 'keymap string)))))
! 	(setq defn (and local-map (lookup-key local-map key)))))
      defn))
  
  (defun help-key-description (key untranslated)
--- 525,554 ----
  	  (princ string)))))
    nil)
  
! (defun string-key-binding (event &optional key)
!   "With some EVENT on a string, return the local binding of KEY.
! If EVENT is an event on a string, and that string has a `local-map'
! or `keymap' property, return the binding of KEY in the string's keymap.
! If KEY is not specified, it is taken from the event."
    (let* ((defn nil)
! 	 (start (when (vectorp event)
! 		  (if (memq (aref event 0)
  			    '(mode-line header-line left-margin right-margin))
! 		      (event-start (aref event 1))
! 		    (and (consp (aref event 0))
! 			 (event-start (aref event 0))))))
  	 (string-info (and (consp start) (nth 4 start))))
      (when string-info
        (let* ((string (car string-info))
  	     (pos (cdr string-info))
! 	     (maps '(keymap local-map))
! 	     local-map)
! 	(when (and (>= pos 0)
! 		   (< pos (length string)))
! 	  (while (and maps (not defn))
! 	    (when
! 		(setq local-map (get-text-property pos (pop maps) string))
! 	      (setq defn (lookup-key local-map (or key event))))))))
      defn))
  
  (defun help-key-description (key untranslated)

[-- Attachment #3: Type: text/plain, Size: 52 bytes --]



-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Getting the click position in a string

[Stefan Monnier]

> But I increasingly feel that this is not the right way to go, the
> whole function should get dissed out, and instead we should have
> something like

> (posn-key-binding event &optional accept-default remap key)

Sounds right.


        Stefan

Re: Getting the click position in a string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> But I increasingly feel that this is not the right way to go, the
>> whole function should get dissed out, and instead we should have
>> something like
>
>> (posn-key-binding event &optional accept-default remap key)
>
> Sounds right.

I have taken a look how the command loop does this right now.  It
appears that read-key-sequence does all the lookup (and it is more or
less necessary to do so in order to decide when a key sequence is
finished), stuffs the looked-up command as a by-product into an
internal variable that appears not accessible at the Lisp level (at a
first glance), and the command loop picks it out from there.

Of all the ugly...

Factoring the keymap and partial keymaps out into a separate function
would probably not be trivial.  But even if code reuse might not be
practical, I think that something like posn-key-binding should be
implemented in keyboard.c so that there is some guarantee it will
deliver the same results.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[Stefan Monnier]

> Factoring the keymap and partial keymaps out into a separate function
> would probably not be trivial.  But even if code reuse might not be
> practical, I think that something like posn-key-binding should be
> implemented in keyboard.c so that there is some guarantee it will
> deliver the same results.

I think it only makes sense to write it in the C code if the resulting code
can be shared with Fread_key_sequence.  Until such a reorg is done, it'd be
good to provide the function in subr.el along the other posn-* functions.

But in order not to make it appear like an "accessor function", maybe it'd
be better to name it differently, e.g. "posn-lookup-key-binding".
Of course, another way to do it is to change `key-binding' so that it
accepts a `posn' argument (and/or an event argument).


        Stefan

Re: Getting the click position in a string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Factoring the keymap and partial keymaps out into a separate function
>> would probably not be trivial.  But even if code reuse might not be
>> practical, I think that something like posn-key-binding should be
>> implemented in keyboard.c so that there is some guarantee it will
>> deliver the same results.
>
> I think it only makes sense to write it in the C code if the resulting code
> can be shared with Fread_key_sequence.  Until such a reorg is done, it'd be
> good to provide the function in subr.el along the other posn-* functions.
>
> But in order not to make it appear like an "accessor function", maybe it'd
> be better to name it differently, e.g. "posn-lookup-key-binding".
> Of course, another way to do it is to change `key-binding' so that it
> accepts a `posn' argument (and/or an event argument).

If it accepted an event instead of a keymap, that would be reasonably
convenient.  There is a certain danger that this extension would be
obscure: people might not know where to look for it in general.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[Stefan Monnier]

>> But in order not to make it appear like an "accessor function", maybe it'd
>> be better to name it differently, e.g. "posn-lookup-key-binding".
>> Of course, another way to do it is to change `key-binding' so that it
>> accepts a `posn' argument (and/or an event argument).

> If it accepted an event instead of a keymap, that would be reasonably
> convenient.  There is a certain danger that this extension would be
> obscure: people might not know where to look for it in general.

XEmacs does it, AFAIK, and I don't find it particularly obscure.


        Stefan

Re: Getting the click position in a string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> But in order not to make it appear like an "accessor function", maybe it'd
>>> be better to name it differently, e.g. "posn-lookup-key-binding".
>>> Of course, another way to do it is to change `key-binding' so that it
>>> accepts a `posn' argument (and/or an event argument).
>
>> If it accepted an event instead of a keymap, that would be reasonably
>> convenient.  There is a certain danger that this extension would be
>> obscure: people might not know where to look for it in general.
>
> XEmacs does it, AFAIK, and I don't find it particularly obscure.

Well, XEmacs has opaque keymaps and/or events, I believe.  For Emacs,
both keymaps as well as events can be cons cells, so I am not sure
eventp and keymapp will always be able to tell them apart.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[Stefan Monnier]

> Well, XEmacs has opaque keymaps and/or events, I believe.  For Emacs,
> both keymaps as well as events can be cons cells, so I am not sure
> eventp and keymapp will always be able to tell them apart.

How's that relevant?  key-binding would not need to distinguish keymaps from
events, but keys from events.


        Stefan

Re: Getting the click position in a string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Well, XEmacs has opaque keymaps and/or events, I believe.  For
>> Emacs, both keymaps as well as events can be cons cells, so I am
>> not sure eventp and keymapp will always be able to tell them apart.
>
> How's that relevant?  key-binding would not need to distinguish
> keymaps from events, but keys from events.

key-binding already looks up events or keys, so I suppose you are
confused about what I was proposing.  The purpose is to look up a key
such as [follow-link] in the chain of keymaps corresponding to a click
event.

So the event takes the place of the keymap, not of the key.  If you
set both key and keymap to the same event, you can look up the binding
of an event in the chain of keymaps associated with the click
position.

If the key is [follow-link] and the keymap is the event, then
[follow-link] will be searched for in all corresponding keymaps.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[Stefan Monnier]

> key-binding already looks up events or keys, so I suppose you are
> confused about what I was proposing.

It accepts events?  That's news to me.

> The purpose is to look up a key such as [follow-link] in the chain of
> keymaps corresponding to a click event.

Yes, that's whayt I understood.

> So the event takes the place of the keymap, not of the key.

What keymap?

   key-binding is a built-in function in `C source code'.
   (key-binding key &optional accept-default no-remap)

I see no keymap argument.


        Stefan

Re: Getting the click position in a string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> key-binding already looks up events or keys, so I suppose you are
>> confused about what I was proposing.
>
> It accepts events?  That's news to me.
>
>> The purpose is to look up a key such as [follow-link] in the chain of
>> keymaps corresponding to a click event.
>
> Yes, that's whayt I understood.
>
>> So the event takes the place of the keymap, not of the key.
>
> What keymap?
>
>    key-binding is a built-in function in `C source code'.
>    (key-binding key &optional accept-default no-remap)
>
> I see no keymap argument.

Probably because I am confusing this with lookup-key.  Looks like I
messed up my proposal royally due to this mixup, and I don't
understand your counterproposal and corresponding arguments either,
most likely because you tried making sense of my nonsense in a way
that I am not able to follow.

So my proposal would _rather_ have been to have lookup-key accept an
event in the place of KEYMAP, where an event means the chain of
keymaps associated with the events.  This does not seem like a
sensible interface since it makes lookup-key either act on a
single-keymap level, or perform a more complex lookup.

So the function to tweak would seem to be rather key-binding after
all.  Instead of making it accept an event as one of the existing
arguments, however, one should probably add another optional argument
which will then augment the "current keymaps" that the function is
supposed to be searching, according to the event.

It would not really suffice to let it accept an event instead of KEY:
for implementing the follow-link functionality, the lookup has to be
for [follow-link], but for a given event of type down-mouse-1 or
similar.

So an additional event specifier seems to be both required and
appropriate.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[Stefan Monnier]

> It would not really suffice to let it accept an event instead of KEY:
> for implementing the follow-link functionality, the lookup has to be
> for [follow-link], but for a given event of type down-mouse-1 or
> similar.

Oh, now I understand what you mean.  So you basically want to add
a `position' argument to `key-binding'?  How 'bout adding a `position'
argument to `current-active-maps'?


        Stefan

Re: Getting the click position in a string

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> It would not really suffice to let it accept an event instead of
>> KEY: for implementing the follow-link functionality, the lookup has
>> to be for [follow-link], but for a given event of type down-mouse-1
>> or similar.
>
> Oh, now I understand what you mean.  So you basically want to add a
> `position' argument to `key-binding'?  How 'bout adding a `position'
> argument to `current-active-maps'?

Well, if we had a lookup function accepting a list of keymaps...  It
seems a bit tiresome to loop all by one's own, so while adding the
argument to `current-active-maps' seems like a good idea, it also
seems like things calling it implicitly (like `key-binding') should
also get that argument.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Getting the click position in a string

[Stefan Monnier]

> Well, if we had a lookup function accepting a list of keymaps...

Well, I do have one ;-)  (as part of a local patch which adds multiple
inheritance to keymaps).

> It seems a bit tiresome to loop all by one's own, so while adding the
> argument to `current-active-maps' seems like a good idea, it also seems
> like things calling it implicitly (like `key-binding') should also get
> that argument.

Of course,


        Stefan