Re: local keymap patch for key-binding

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

> Why add the argument LOCATION?  Is it just for the sake of
> command-rebinding?

See the more elaborate explanation in a recent mail.

> Why the need to switch buffers?

Because the values of overriding-local-map and the current minor maps
might depend on it.  The buffer-local maps for the lookup of a mouse
event are taken from the buffer where the mouse event occured, not the
currently selected buffer.

> Aside from that, some little details:
>
>     + 	* keymap.c: include "window.h".
>
> You need to add a dependency in Makefile.in for that.

Ouch.  Yes.

>     !       if (SYMBOLP (AREF(location,0)) && ASIZE(location) > 1)
>     ! 	event = AREF(location,1);
>     !       else
>     ! 	event = AREF(location,0);
>
> To follow our coding style you need additional spaces here:
>
>     !       if (SYMBOLP (AREF (location,0)) && ASIZE (location) > 1)
>     ! 	event = AREF (location, 1);
>     !       else
>     ! 	event = AREF (location, 0);
>
> A comma should always be followed by a space.
> Outside of a parenthesis there must be a space,
> unless the same spot is inside another parenthesis
> or followed by a semicolon.

OK, will do.

> There needs to be documentation for LOCATION in etc/NEWS and the Lisp
> Manual.

Well, I wanted to get the code right (and use it) before tackling
those: and indeed, LOCATION has already morphed into POSITION because
the latter is more useful for mouse.el...

I would want to postpone the entries until I have finished recoding
the use cases of this functionality, and they test out well.  That
way, I don't need to rewrite stuff in case the API turns out not to do
the trick.

>     ! 	  /* Key sequences beginning with mouse clicks are
>     ! 	     read using the keymaps in the buffer clicked on,
>     ! 	     not the current buffer.  If we're at the
>     ! 	     beginning of a key sequence, switch buffers.  */
>
> I can't understand the second sentence, "If we're at the beginning
> of a key sequence".  Since key-binding always operates on a key
> sequence, and since we're not in the middle of a loop which scans
> that key sequence, what does it mean to say that we are, or are not,
> "at the beginning" of it?

Uhm, well, it means that this comment was copied and pasted from
keyboard.c (which has similar functionality) and not fully rewritten.

I'll change that.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum