[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#5264: 23.1; `repeat' should not hard-code the set of affected comman
From: |
Lars Ingebrigtsen |
Subject: |
bug#5264: 23.1; `repeat' should not hard-code the set of affected commands |
Date: |
Wed, 27 Apr 2016 23:17:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
"Drew Adams" <drew.adams@oracle.com> writes:
> In the definition of command `repeat':
>
> (if (memq last-repeatable-command
> '(exit-minibuffer
> minibuffer-complete-and-exit
> self-insert-and-exit))
>
> This list of affected commands should not be hard-coded. If user code
> uses different functions from `exit-minibuffer' and
> `minibuffer-complete-and-exit', then users must redefine `repeat' to
> accommodate this command difference. The `repeat' definition should
> be more flexible than that.
>
> This list of commands should be treated the same way we treat the list
> of dangerous commands (`repeat-too-dangerous'): define a variable
> whose value is the list of commands - do not hard-code the list.
But what it is this does? If `last-repeatable-command' is any of these
commands, then we... repeat the first command in `command-history'
instead? What does that do, exactly?
(if (memq last-repeatable-command '(exit-minibuffer
minibuffer-complete-and-exit
self-insert-and-exit))
(let ((repeat-command (car command-history)))
(repeat-message "Repeating %S" repeat-command)
(eval repeat-command))
(if (null repeat-arg)
(repeat-message "Repeating command %S" last-repeatable-command)
(setq current-prefix-arg repeat-arg)
(repeat-message
"Repeating command %S %S" repeat-arg last-repeatable-command))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#5264: 23.1; `repeat' should not hard-code the set of affected commands,
Lars Ingebrigtsen <=