emacs-devel
[Top][All Lists]
Advanced

[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
-- 



reply via email to

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