Re: Suggestion: Simple way to make conditional key bindings.

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

> > 
> > But IMO, the `menu-item' syntax is awful, and using a
> 
> If the problem is only syntax, feel free to create an appropriate macro.
> 
> > filter function is an added complexity which is pretty
> > unflexible.
> 
> What do you mean by `complexity' ?

Using code is not "self-contained"; in contrast, key bindings made by
one elisp package is typically independent of the key bindings made by
other packages.  So using code is more complex than key bindings.

> You want to have a code.  That's what functions are for.  I think `eval'
> should generally be avoided, and `funcall' used instead.
> This is especially true if we care about lexical scoping.

I don't quite follow, but I take your word for it :-)

> 
> One problem with your change is "what binding do we use when we don't want
> to run code?".  The `menu-item' syntax provides a binding (in the example
> above it's "my-filter" which is not very useful indeed) for the case
> where code should not be evalled (for example in `where-is').

Who said we don't want to run code :-)

Ok, I can see that could be a problem if we cache the result.
But I guess we can just use the "default" binding, i.e. the last
element (t ...) in the cond [and nil if no such element is present].

> 
> > It will then be quite trivial to enhance `define-key' to handle
> > conditional bindings:
> 
> But is it desirable ?

Don't really know...   It seems like a simple approach to allow
packages to hook into "standard bindings".

> 
> > (define-key global-map "\C-y" 'yank)  ; this sets the default
> > 
> > (define-key global-map "\C-y" 'yank-with-properties
> >         '(and kill-ring (table-recognize-table (car kill-ring))))
> > 
> > The second call would automatically changes the non-cond binding into
> > a cond binding with the previous binding as default.
> 
> Why not
> 
>   (define-key global-map "\C-y" 'yank-careful)
>   (defun yank-careful (...)
>     "Reinsert the last stretch of killed text, like `yank'.
>   Contrary to `yank' this function is careful to preserve some important
>   text properties when yanking tables."
>     ...)

The point is that you can install a package - like table.el - which is
then able to install its own conditional binding on C-y *without*
interferring with (or even knowning) the standard binding.

Suppose we have a conditional binding like this

  (define-key global-map "\C-y" 'yank-rectangle
        '(rectangle-p (car kill-ring)))

to be able to insert rectangles from the kill-ring using C-y.

Then table.el would still be able to install its own conditional
binding on C-y.


> 
> The advantage is that C-h k C-y doesn't just give you one of the two
> bindings but a docstring that describes both.  Of course we could also
> improve C-h k to recognize your `cond' construct, etc... but is it
> really worth the trouble ?

I didn't think about that, but it would be a nice way to report such
"multiple" bindings on a key...

But you may also consider this as a different approach than using a
minor-mode-keymap, and in that case, I think C-h k doesn't report all
possible bindings for a key -- only the "currently active" binding, so
why does `cond' have to behave differently?

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