emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] emacs-25 bc55a57: * lisp/menu-bar.el (kill-this-buffer


From: Stefan Monnier
Subject: Re: [Emacs-diffs] emacs-25 bc55a57: * lisp/menu-bar.el (kill-this-buffer): Doc fix. (Bug#26466)
Date: Wed, 12 Apr 2017 16:27:44 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

> +This command can be reliably invoked only from the menu bar,
> +otherwise it could decide to silently do nothing."

All this is due to:

    commit a86b330f8fa754c4b919ea14d0c5dcf261f055c4
    Author: Juri Linkov <address@hidden>
    Date:   Sun Mar 16 17:44:20 2008 +0000
    
        (kill-this-buffer): Use menu-bar-non-minibuffer-window-p
        to check if the current buffer is the minibuffer, and in this case
        call abort-recursive-edit to kill the minibuffer.  Doc fix.
        (kill-this-buffer-enabled-p): Allow this function to return non-nil
        when the current buffer is the minibuffer.
    
    diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
    --- a/lisp/menu-bar.el
    +++ b/lisp/menu-bar.el
    @@ -1444,1 +1446,3 @@
    -  (kill-buffer (current-buffer)))
    +  (if (menu-bar-non-minibuffer-window-p)
    +      (kill-buffer (current-buffer))
    +    (abort-recursive-edit)))

Jury, do you remember why we wanted this behavior?
There are two questions here:
- Why would we want to run abort-recursive-edit when we're in the minibuffer?
- Why did we decide to use menu-bar-non-minibuffer-window-p rather than
  checking something like (window-minibuffer-p (frame-selected-window))?

I think there should be a way to make kill-this-buffer behave sanely
just as much when called from the menu-bar as called from M-x [ I'm not
concerned about calling it from Elisp and I'm perfectly happy to mark it
`interactive-only`.  ]


        Stefan



reply via email to

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