Re: On keybindings and the slow erosion of help's utility

>> If the last command is also a partial binding and it doesn't match, then
>> we can do something similar to calling `undefined`, tho maybe with
>> a tweaked message.  I don't see any difficulty here.  Am I missing something?
>
> Yes. Consider that we want to define the partial binding in
> foo-minor-mode-map. If nothing match, we also want to continue resolving
> the keymaps in the usual order.

That's not a problem: the main point I'm proposing is that the keymap
lookup looks at all the keymap and builds an overall
`composite-command`.  So, different pieces can be in different keymaps
and get combined into a single `composite-command` during the
key lookup.

>>>> should each call completely override the previous (so after those three
>>>> calls we have just a single partial binding that uses `my-bar3` when
>>>> `my-condition1` is true)?  Or should we just accumulate them (if so,
>>>> how do we remove a partial binding without removing them all)?
>>>> Or should the third call override the first but not the second (and presumably
>>>> allow `(keymap-set ...(make-partial-binding #'my-condition1 nil))`
>>>> to remove one of the partial bindings)?
>>>>
>>>> The third option sounds more flexible, but it requires more changes in
>>>> the `keymap.c` code.
>>>
>>> IMHO, the best approach is to make the full "partial-binding" named and the
>>> each condition also named (as in my suggestion with :name). I described
>>> examples earlier. I think that exactly the same structure can be used to
>>> manipulate the conditions. (I hope what I said in this paragraph makes sense)
>>
>> I'm afraid I don't understand how what you say relates to what I said.
>
> In my earlier emails I described my idea how to solve the problem you are
> describing - about adding and removing the conditions in certain order.
> Instead of implicit replace/append, I suggested to adopt
> add-hook semantics with passing priorities and an ability to remove the
> existing bindings (like in remove-hook).

IIUC you're saying that each keymap can have only one partial-command
binding and if you want that binding to itself be composed of other
partial-bindings, then you need to do it via some other mechanism such
as a hook.

That means you're selecting the first option of the three (i.e. "each
keymap-set call completely override the previous").

>>>> Also, in the above I assume that we're not interested in something like
>>>>     (keymap-set foo-mode-map "TAB" (make-partial-binding #'my-condition1 my-keymap))
>>> I am not sure why we need to introduce such a limitation vs. what I proposed.
>>
>> Because what I'm describing moves the execution of the conditions to the
>> moment we run the command, rather than the keymap-lookup, so it's late
>> to do further key processing.
>
>> Strictly speaking, it would be possible, e.g. to call `popup-menu` after
>> evaluating the conditions if the chosen option is a keymap, but it
>> wouldn't integrate as well into the command loop and things like `C-h k`.
>
> I thought that one of the first problems raised in this thread was
> exactly the integration with C-h k.

Indeed, which is why I'd rather not go there: only consider the case
where all the partial bindings are commands (where we'd use the
`composite-command`) and the case where all the partial bindings are
keymaps (where we're stuck with something very close to the current
`menu-item`) but not the mixed case.


=== Stefan