>> I could send a patch that fixes this bug. > > Thanks. I hoped first to understand why we bind > enable-recursive-minibuffers in these cases, but if you prefer to > begin with a patch, please do, and let's take it from there. To understand the problem, it's better to start from the manual. The node (info "(elisp) Recursive Mini") says: If a command name has a property ‘enable-recursive-minibuffers’ that is non-‘nil’, then the command can use the minibuffer to read arguments even if it is invoked from the minibuffer. A command can also achieve this by binding ‘enable-recursive-minibuffers’ to ‘t’ in the interactive declaration (*note Using Interactive::). The minibuffer command ‘next-matching-history-element’ (normally ‘M-s’ in the minibuffer) does the latter. And indeed the command ‘next-matching-history-element’ (‘M-s’) mentioned as an example in the documentation, exhibits the same problem reported by Richard: 0. emacs -Q 1. M-x ;; execute-extended-command 2. M-s ;; next-matching-history-element 3. C-x b ;; switch-to-buffer And it tries to read a buffer name, ignoring the default nil value of ‘enable-recursive-minibuffers’. This is because the manual documents the official way by binding ‘enable-recursive-minibuffers’ to ‘t’ that next-matching-history-element does: (defun next-matching-history-element (regexp n) (interactive (let* ((enable-recursive-minibuffers t) (regexp (read-from-minibuffer "Next element matching (regexp): " ... One possible solution is to support an additional value ‘transient’ for the variable ‘enable-recursive-minibuffers’. Then this value could have its effect only for the next invocation of read-from-minibuffer. Afterwards it will be set to ‘nil’ for any further recursive calls of read-from-minibuffer. PS: Such transient value is similar to the value ‘lambda’ of ‘transient-mark-mode’ described in (info "(elisp) The Mark"). Currently this patch fixes the reported problem only for the commands yes-or-no-p and next-matching-history-element: