[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: local keymap patch for key-binding

From: David Kastrup
Subject: Re: local keymap patch for key-binding
Date: Wed, 13 Sep 2006 14:32:28 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
>> address@hidden (Kim F. Storm) writes:
>>> Your patch still looks good to me.
>> Well, I could not witness any adverse effect after some testing, it
>> tracks the behavior of read-key-sequence closely.
>> There is one concern that I have: the type of the "location" argument.
>> This currently is a key sequence.  But it might make more sense to
>> turn this into the "location" data structure that `event-start' and/or
>> `event-end' return.  This would make it much easier to feed lookup-key
>> with data produced from, say, `posn-at-x-y'.
> I overlooked that part -- I actually thought it was such a location.
>> In order to get this data easier, it might make sense to define a
>> convenience function.
>> (defun key-event (key)
>>    "Return event from moused-base key sequence KEY."
>>    (and (vectorp key)
>>         (if (consp (aref key 0))
>>             (aref key 0)
>>           (and
>>             (symbolp (aref key 0))
>>             (> (length key) 1)
>>             (consp (aref key 1))
>>             (aref key 1)))))
>> Maybe even in C, as this function can be executed without consing.
> That is usually not the normal way to decide what should be in C...
>> I found that the current usage in the help echo fixup stuff does
>> not even have a key sequence to start from, just a mouse position.
>> So it would likely make more sense to rework the location argument
>> type to just be a mouse position.
> in pixels or chars?

In the form returned by `event-start' or `posn-at-x-y'.  One does not
want to look up the object relations in the display matrix again,
since those may have changed since the event.

>> That seems like the most basic unit for this argument that still
>> makes sense.
> True, but shouldn't it accept both types ...

I don't see that this will buy much over using

(let ((event (key-event key)))
  (key-binding whatever nil nil (and event (event-start event))))

once the convenience function key-event (or key-mouse-event or what
ever you want to call it) is present (note that (event-start nil) does
not return nil).

It also has the advantage that you can, if you want to, do a lookup in
the keymaps at the _end_ of a drag event.

> if you already have the full event, it seems wasteful to first
> convert it to just a mouse position, pass that to key-binding and
> then use that to derive what the original event was (eg. using
> posn-at-x-y).

No, I am afraid you misunderstood.  I mentioned `posn-at-x-y' only for
the case where indeed nothing but pixel coordinates exist.

I wanted to use a `location' argument as returned by `event-start'.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]