FW: Minibuf menu when minibuffer is standalone

FW: Minibuf menu when minibuffer is standalone

[Drew Adams]

Resending.

From: Drew Adams Sent: Sunday, July 01, 2007 8:26 AM
Resending, since the release is now out.

> From: Drew Adams Sent: Sunday, May 20, 2007 1:02 PM  
> Consider as a possible enhancement somehow making the Minibuf 
> menu-bar menu available also when the minibuffer is in a
> standalone frame (frame parameter minibuffer has value `only').
> 
> Because the minibuffer maps are local maps, when you have a
> standalone minibuffer frame, which has no menu-bar, the Minibuf
> menu-bar menu is not available anywhere. (The other frames do
> not have minibuffers, and their buffers do not have the
> minibuffer map as local map.)
> 
> Perhaps menu Minibuf could somehow be made to appear in all 
> frames that have a menu-bar, whenever the minibuffer is active.
> I'm not sure how that might be implemented, because it is good
> to keep the current situation of the minibuffer maps being
> local to the minibuffer. But if a good implementation could be
> found, it would be desirable to have the Minibuf menu available
> also for users who have a standalone minibuffer.

Re: FW: Minibuf menu when minibuffer is standalone

[Lennart Borgman (gmail)]

Drew Adams wrote:
> Resending.
> 
> From: Drew Adams Sent: Sunday, July 01, 2007 8:26 AM
> Resending, since the release is now out.
> 
>> From: Drew Adams Sent: Sunday, May 20, 2007 1:02 PM  
>> Consider as a possible enhancement somehow making the Minibuf 
>> menu-bar menu available also when the minibuffer is in a
>> standalone frame (frame parameter minibuffer has value `only').
>>
>> Because the minibuffer maps are local maps, when you have a
>> standalone minibuffer frame, which has no menu-bar, the Minibuf
>> menu-bar menu is not available anywhere. (The other frames do
>> not have minibuffers, and their buffers do not have the
>> minibuffer map as local map.)
>>
>> Perhaps menu Minibuf could somehow be made to appear in all 
>> frames that have a menu-bar, whenever the minibuffer is active.
>> I'm not sure how that might be implemented, because it is good
>> to keep the current situation of the minibuffer maps being
>> local to the minibuffer. But if a good implementation could be
>> found, it would be desirable to have the Minibuf menu available
>> also for users who have a standalone minibuffer.


Maybe as a popup menu bound to <apps> when the minibuffer is active?

Re: FW: Minibuf menu when minibuffer is standalone

[Stefan Monnier]

>> From: Drew Adams Sent: Sunday, May 20, 2007 1:02 PM  
>> Consider as a possible enhancement somehow making the Minibuf 
>> menu-bar menu available also when the minibuffer is in a
>> standalone frame (frame parameter minibuffer has value `only').
>> 
>> Because the minibuffer maps are local maps, when you have a
>> standalone minibuffer frame, which has no menu-bar, the Minibuf
>> menu-bar menu is not available anywhere. (The other frames do
>> not have minibuffers, and their buffers do not have the
>> minibuffer map as local map.)
>> 
>> Perhaps menu Minibuf could somehow be made to appear in all 
>> frames that have a menu-bar, whenever the minibuffer is active.
>> I'm not sure how that might be implemented, because it is good
>> to keep the current situation of the minibuffer maps being
>> local to the minibuffer. But if a good implementation could be
>> found, it would be desirable to have the Minibuf menu available
>> also for users who have a standalone minibuffer.

Actually, I'd hate such a behavior.  It's only relatively recently
(maybe a couple years) that I discovered the minibuffer menus, where
I tested Emacs in a non-separate-minibuffer-frame setting and found the
menu-bar switching just inconvenient.

I mean, really, all that menu-bar-switching for what?
3 miserable commands?


        Stefan

Re: FW: Minibuf menu when minibuffer is standalone

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>> From: Drew Adams Sent: Sunday, May 20, 2007 1:02 PM  
>>> Consider as a possible enhancement somehow making the Minibuf 
>>> menu-bar menu available also when the minibuffer is in a
>>> standalone frame (frame parameter minibuffer has value `only').
>>>
>>> Because the minibuffer maps are local maps, when you have a
>>> standalone minibuffer frame, which has no menu-bar, the Minibuf
>>> menu-bar menu is not available anywhere. (The other frames do
>>> not have minibuffers, and their buffers do not have the
>>> minibuffer map as local map.)
>>>
>>> Perhaps menu Minibuf could somehow be made to appear in all 
>>> frames that have a menu-bar, whenever the minibuffer is active.
>>> I'm not sure how that might be implemented, because it is good
>>> to keep the current situation of the minibuffer maps being
>>> local to the minibuffer. But if a good implementation could be
>>> found, it would be desirable to have the Minibuf menu available
>>> also for users who have a standalone minibuffer.
> 
> Actually, I'd hate such a behavior.  It's only relatively recently
> (maybe a couple years) that I discovered the minibuffer menus, where
> I tested Emacs in a non-separate-minibuffer-frame setting and found the
> menu-bar switching just inconvenient.
> 
> I mean, really, all that menu-bar-switching for what?
> 3 miserable commands?


For learning perhaps? Maybe not very useful for you though ... ;-)

However looking at the Minibuff menu when doing C-x C-f in CVS Emacs 23 
I see a little bit strangeness:

   Minibuff
    Complete -- TAB
    Complete Word
    List Completions -- ?
    Previous History Item -- M-p
    Next History Item -- M-n
    Isearch History Backward -- C-r
    Isearch History Forward -- C-s
    Enter -- C-j
    Quit -- M-ESC ESC

I would perhaps expect some to be different

    Previous History Item -- up
    Next History Item -- down
    Quit -- C-g

It seems like the choice of keybinding to show could be done better.

    Enter -- C-j

I do not understand that one at all.

Re: FW: Minibuf menu when minibuffer is standalone

[Stefan Monnier]

> For learning perhaps? Maybe not very useful for you though ... ;-)

> However looking at the Minibuff menu when doing C-x C-f in CVS Emacs 23
> I see a little bit strangeness:

>   Minibuff
>    Complete -- TAB
>    Complete Word
>    List Completions -- ?
>    Previous History Item -- M-p
>    Next History Item -- M-n
>    Isearch History Backward -- C-r
>    Isearch History Forward -- C-s
>    Enter -- C-j
>    Quit -- M-ESC ESC

> I would perhaps expect some to be different

>    Previous History Item -- up
>    Next History Item -- down
>    Quit -- C-g

> It seems like the choice of keybinding to show could be done better.

The Quit one looks bad indeed.  The other 2 are right: we want to show
the bindings which work everywhere whenever possible, whereas `up' and
`down' keys may not always be available.

>    Enter -- C-j

> I do not understand that one at all.

That's not too good either, indeed, but I don't see it here (it just
doesn't say anything at all for me).


        Stefan

Re: FW: Minibuf menu when minibuffer is standalone

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>> For learning perhaps? Maybe not very useful for you though ... ;-)
> 
>> However looking at the Minibuff menu when doing C-x C-f in CVS Emacs 23
>> I see a little bit strangeness:
> 
>>   Minibuff
>>    Complete -- TAB
>>    Complete Word
>>    List Completions -- ?
>>    Previous History Item -- M-p
>>    Next History Item -- M-n
>>    Isearch History Backward -- C-r
>>    Isearch History Forward -- C-s
>>    Enter -- C-j
>>    Quit -- M-ESC ESC
> 
>> I would perhaps expect some to be different
> 
>>    Previous History Item -- up
>>    Next History Item -- down
>>    Quit -- C-g
> 
>> It seems like the choice of keybinding to show could be done better.
> 
> The Quit one looks bad indeed.  The other 2 are right: we want to show
> the bindings which work everywhere whenever possible, whereas `up' and
> `down' keys may not always be available.

It is a difficult choice what to choose, but I would prefer up/down for 
beginners. Are there really any cases where up/down are not available today?

>>    Enter -- C-j
> 
>> I do not understand that one at all.
> 
> That's not too good either, indeed, but I don't see it here (it just
> doesn't say anything at all for me).

Emacs 23.0.60.1, 2008-03-10.

But I can't understand why "Enter" should be in the menu. It is really 
not surprising that you press ENTER to enter the data, or is it? Of 
course I see a lot of people entering data in a web browser using the 
mouse to click the submit button, but I do not think anyone of them uses 
Emacs ...

Re: FW: Minibuf menu when minibuffer is standalone

[Stefan Monnier]

>>> Enter -- C-j
>> 
>>> I do not understand that one at all.
>> 
>> That's not too good either, indeed, but I don't see it here (it just
>> doesn't say anything at all for me).

> Emacs 23.0.60.1, 2008-03-10.

Yes, I saw it in the end.  If you do a M-x before, it gets removed, tho.

> But I can't understand why "Enter" should be in the menu. It is really not
> surprising that you press ENTER to enter the data, or is it? Of course I see
> a lot of people entering data in a web browser using the mouse to click the
> submit button, but I do not think anyone of them uses Emacs ...

It's actually worse than that: the binding for "Enter" is
exit-minibuffer which is wrong for completions that "require-match"
(such as M-x) which should instead use minibuffer-complete-and-exit
(which is why the binding is not shown when you do M-x: in that case
exit-minibuffer is not bound to any key).

In any case I've changed the Quit to use the same binding as C-g (so
C-g is shown in the shortcuts) and tweaked the "Enter" entry so it shows
RET (or thing) rather than C-j (or nothing).


        Stefan

Re: FW: Minibuf menu when minibuffer is standalone

[Juri Linkov]

> In any case I've changed the Quit to use the same binding as C-g (so
> C-g is shown in the shortcuts) and tweaked the "Enter" entry so it shows
> RET (or thing) rather than C-j (or nothing).

BTW, a similar thing could be done to the toolbar.  The "kill" icon on
the toolbar kills the current buffer, but it is greyed out when the
minibuffer is active.  However, it is natural from the user's point of
view to expect that clicking on this icon will "kill" the minibuffer
when it is active.  Internally, killing the normal buffer and the
minibuffer is implemented by separate functions, but for the user of
the toolbar this distinction is not essential.

I propose the following patch that enables the kill icon in the minibuffer
and calls `abort-recursive-edit' when clicked on.  This makes more
conventient for mouse users to get out of the minibuffer.

Index: lisp/menu-bar.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/menu-bar.el,v
retrieving revision 1.323
diff -c -r1.323 menu-bar.el
*** lisp/menu-bar.el	11 Mar 2008 22:02:46 -0000	1.323
--- lisp/menu-bar.el	13 Mar 2008 02:00:19 -0000
***************
*** 1439,1447 ****
      (not (window-minibuffer-p (frame-selected-window menu-frame)))))
  
  (defun kill-this-buffer ()	; for the menu bar
!   "Kill the current buffer."
    (interactive)
!   (kill-buffer (current-buffer)))
  
  (defun kill-this-buffer-enabled-p ()
    (let ((count 0)
--- 1439,1451 ----
      (not (window-minibuffer-p (frame-selected-window menu-frame)))))
  
  (defun kill-this-buffer ()	; for the menu bar
!   "Kill the current buffer.
! When called in the minibuffer, get out of the minibuffer
! using `abort-recursive-edit'."
    (interactive)
!   (if (menu-bar-non-minibuffer-window-p)
!       (kill-buffer (current-buffer))
!     (abort-recursive-edit)))
  
  (defun kill-this-buffer-enabled-p ()
    (let ((count 0)
***************
*** 1450,1457 ****
        (or (string-match "^ " (buffer-name (car buffers)))
  	  (setq count (1+ count)))
        (setq buffers (cdr buffers)))
!     (and (menu-bar-non-minibuffer-window-p)
! 	 (> count 1))))
  
  (put 'dired 'menu-enable '(menu-bar-non-minibuffer-window-p))
  
--- 1454,1461 ----
        (or (string-match "^ " (buffer-name (car buffers)))
  	  (setq count (1+ count)))
        (setq buffers (cdr buffers)))
!     (or (not (menu-bar-non-minibuffer-window-p))
! 	(> count 1))))
  
  (put 'dired 'menu-enable '(menu-bar-non-minibuffer-window-p))

-- 
Juri Linkov
http://www.jurta.org/emacs/

RE: FW: Minibuf menu when minibuffer is standalone

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 2748 bytes --]

> >> Consider as a possible enhancement somehow making the Minibuf 
> >> menu-bar menu available also when the minibuffer is in a
> >> standalone frame (frame parameter minibuffer has value `only').
> >> 
> >> Because the minibuffer maps are local maps, when you have a
> >> standalone minibuffer frame, which has no menu-bar, the Minibuf
> >> menu-bar menu is not available anywhere. (The other frames do
> >> not have minibuffers, and their buffers do not have the
> >> minibuffer map as local map.)
> >> 
> >> Perhaps menu Minibuf could somehow be made to appear in all 
> >> frames that have a menu-bar, whenever the minibuffer is active.
> >> I'm not sure how that might be implemented, because it is good
> >> to keep the current situation of the minibuffer maps being
> >> local to the minibuffer. But if a good implementation could be
> >> found, it would be desirable to have the Minibuf menu available
> >> also for users who have a standalone minibuffer.
> 
> Actually, I'd hate such a behavior.  It's only relatively recently
> (maybe a couple years) that I discovered the minibuffer menus, where
> I tested Emacs in a non-separate-minibuffer-frame setting and 
> found the menu-bar switching just inconvenient.
> 
> I mean, really, all that menu-bar-switching for what?
> 3 miserable commands?

Any such argument can be levelled equally agains the Minibuf menu in general
- it has nothing to do with the suggestion to make the existing menu
available to people who use a standalone minibuffer.

Are you suggesting that we remove the Minibuf menu altogether? If so, then
yes, let's answer that question first. If the answer is that it should be
kept, then my question remains: Why not also make it available somehow for
those with a standalone minibuffer?

Wrt "all that menu-bar switching": Does that mean that you are also against
the dynamic changing of menus in general, or at least when they have
relatively few items?

Wrt "3 miserable commands": 1. The number of commands shouldn't be a very
important argument for keeping or tossing a menu. 2. Other applications
might add additional items to the menu. In Icicles, for example, the Minibuf
menu has all of the items in the attached screenshot. There are more than "3
miserable commands" there. And, as Lennart pointed out, menus can help you
learn what's available and what key bindings there are - it's a lot quicker
to check some things that way than consult the manual, even in Emacs.

Out of curiosity, do you use menus at all? If not, do you at least see their
value for others? I'm wondering if your response is about just the Minibuf
menu or all menus. Let's separate the concerns, please. My question is in
the context where Emacs will continue to have a Minibuf menu.


[-- Attachment #2: drew-emacs-Minibuf-menu.PNG --]
[-- Type: image/png, Size: 12185 bytes --]