[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 29.0.60; keymap-local-set and keymap-global-set became less strict
From: |
Robert Pluim |
Subject: |
Re: 29.0.60; keymap-local-set and keymap-global-set became less strict |
Date: |
Tue, 31 Jan 2023 16:48:02 +0100 |
>>>>> On Tue, 31 Jan 2023 17:06:21 +0200, Eli Zaretskii <eliz@gnu.org> said:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Daniel Mendler <mail@daniel-mendler.de>, emacs-devel@gnu.org,
Stefan
>> Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>
>> Date: Tue, 31 Jan 2023 10:05:15 +0100
>>
Lars> So keymap-local-set and keymap-global-set should be fixed to be strict
Lars> again, otherwise there's not much point to the entire `keymap-*'
Lars> exercise.
>>
>> OK. How about this then (why are the `cursor-in-echo-area' shenanigans
>> necessary? I wonder if thatʼs a bug, since without them we either get
>> the cursor not showing in the minibuffer for
>> `read-key-sequence-vector', or we get an extra space displayed by
>> `read-command')
Eli> Why does it have to be so complicated, though? If the problem is not
Eli> to call key-description in non-interactive invocations, can't we call
Eli> key-description inside the interactive form? Or use some other trick
Eli> to invoke key-description only in interactive calls?
? Weʼre only calling key-description inside `interactive' in the
patch.
Ideally Iʼd like to use a format string to `interactive', and
massage the results, but I donʼt think thatʼs possible (Iʼd love to be
wrong).
I guess we could use `called-interactively-p', but thatʼs frowned upon,
or add an optional `interactive' arg thatʼs set to `t' by the
`interactive' call, but that all feels messy.
Or we add a new interactive spec: 'Κ' that does the same as 'K' but
calls `key-description' (Iʼm joking)
Robert
--