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: Juri Linkov
Subject: Re: [Emacs-diffs] emacs-25 bc55a57: * lisp/menu-bar.el (kill-this-buffer): Doc fix. (Bug#26466)
Date: Thu, 13 Apr 2017 01:03:50 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (x86_64-pc-linux-gnu)

>> +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?

I clearly remember that the intention was to discard the minibuffer when
the user clicks on the big cross, i.e. the "Close" button in the toolbar,
because its mnemonics suggests to close the currently active buffer -
if it's the minibuffer, then close the minibuffer.

It also makes sense to do the same when the menu item "Close" is selected
from the "File" menu due to its definition:

    (bindings--define-key menu [kill-buffer]
      '(menu-item "Close" kill-this-buffer
                  :enable (kill-this-buffer-enabled-p)
                  :help "Discard (kill) current buffer"))

where "Discard (kill) current buffer" could also apply to the currently
active minibuffer.

> - Why did we decide to use menu-bar-non-minibuffer-window-p rather than
>   checking something like (window-minibuffer-p (frame-selected-window))?

‘menu-bar-non-minibuffer-window-p’ already does this, and additionally
takes into account ‘menu-updating-frame’ and checks for ‘frame-live-p’.

> 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`.  ]

In any case it makes no sense to add special-casing for the minibuffer in
‘kill-current-buffer’ since it is necessary only in ‘kill-this-buffer’
associated with the tool-bar/menu-bar.  ‘kill-current-buffer’ should be
just an alias for ‘(kill-buffer (current-buffer))’.



reply via email to

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