From: David Reitter <david.reitter@gmail.com>
Cc: juri@jurta.org, emacs-devel@gnu.org
Subject: Re: menu-bar: disable items when no frame visible
Date: Sun, 25 Dec 2005 10:54:07 +0100 [thread overview]
Message-ID: <574B84E7-DF6B-4220-BE7E-9AE69AFF135D@gmail.com> (raw)
In-Reply-To: <E1EqLyk-0007ap-BN@fencepost.gnu.org>
On 25 Dec 2005, at 03:51, Richard M. Stallman wrote:
> But I would suggest improving find-file to catch the error in
> switch-
> to-buffer and show the buffer in another window in that case, at
> least when called interactively.
>
> Why do you find it so often useful to invoke Find File
> while you're in a minibuffer?
Usually I have started something else which reads an argument in the
minibuffer, either in error or because I'd like to look up something
in another file in order to supply the right input. This applies to
invoking switch-to-buffer with the same reasoning -- you'd like to
look up something else.
WIthout having counted these cases, I'd say the majority of cases is
erroneous invoking of the first command that gets me to the
minibuffer. (Of course, I should do C-g, but that doesn't happen.)
That's why I've been looking for a way to enable "sequential" instead
of "recursive" minibuffers (see my recent message below).
Either method (switch-to-buffer using a different window if in
minibuffer and interactive, and: sequential minibuffers) address
similar situations and would be of benefit at least to the
inexperienced user.
Begin forwarded message:
From: david.reitter@gmail.com
Subject: Sequential instead of recursive minibuffers?
Date: 15 December 2005 20:02:28 GMT+01:00
To: Help-gnu-emacs@gnu.org
Is it possible to automatically signal a `quit' to the current
minibuffer prompt function when another minibuffer is set up?
We've had a discussion back in summer:
http://lists.gnu.org/archive/html/help-gnu-emacs/2005-07/msg00021.html
To explain this a little further: I can currently choose between
normal (simple) minibuffers and recursive minibuffers.
The difference is in the behavior if a user presses a key sequence
bound to an interactive command, sees the prompt and decides that it
was the wrong command. Now (without a C-g in between) he remembers
the correct command and enters that one.
The first option will always signal an error ("Command attempted to
use minibuffer while in minibuffer"), which is somewhat confusing and
certainly annoying to me. A couple of months ago, when I didn't know
anything about this minibuffer business, I was confused big time!
The "recursive minibuffer" setting will do just what it says - which
means that the old prompt will reappear as soon as the new command is
finished. This is equally confusing, in particular to new users. I
often get caught in situations where several minibuffers stack up and
I have to C-g several times to get out of the situation.
In the previously mentioned discussion, some UI-based workarounds
have been proposed (e.g. different colors depending on minibuffer
state).
What I'd like to configure in my Emacs is a sequential minibuffer: As
soon as I enter another interactive command, the currently running
one is quit. My first attempt at doing that was
(setq enable-recursive-minibuffers nil)
(add-hook 'minibuffer-setup-hook
'keyboard-quit)
which fails because `keyboard-quit' is, of course, executed in the
wrong context.
Again, the logic could be:
- if we're in an interactive command (call-interactively) that uses
the minibuffer (A)
- and another interactive is called (but not via a minibuffer-
specific keymap) which prompts for some input in the minibuffer (B)
then signal 'quit' to A and continue with B.
That way I can do M-x M-x ...., or something like C-x C-f di C-h
f ding RET (where I confused C-h f with C-x C-f) without any error
messages, without remaining minibuffers that I don't want and with
exactly the desired result.
I have no idea how to accomplish this -- any suggestions would be
appreciated.
next prev parent reply other threads:[~2005-12-25 9:54 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-10 15:57 menu-bar: disable items when no frame visible David Reitter
2005-11-10 16:03 ` David Reitter
2005-11-10 21:12 ` David Reitter
2005-11-12 3:38 ` Richard M. Stallman
2005-11-12 7:11 ` Eli Zaretskii
2005-11-12 21:21 ` Richard M. Stallman
2005-11-12 22:44 ` Eli Zaretskii
2005-11-28 0:21 ` David Reitter
2005-11-28 5:32 ` Eli Zaretskii
2005-11-28 20:23 ` Juri Linkov
2005-11-28 21:00 ` Richard M. Stallman
2005-11-28 22:20 ` David Reitter
2005-11-28 22:46 ` Jason Rumney
2005-11-29 10:32 ` Reiner Steib
2005-11-29 21:48 ` Richard M. Stallman
2005-12-06 0:54 ` Juri Linkov
2005-12-06 16:43 ` Richard M. Stallman
2005-12-07 0:45 ` Juri Linkov
2005-12-07 22:58 ` Richard M. Stallman
2005-12-12 8:23 ` Jan D.
2005-12-12 21:14 ` Eli Zaretskii
2005-12-13 7:19 ` Jan Djärv
2005-12-13 20:24 ` Eli Zaretskii
2005-12-14 17:03 ` Juri Linkov
2005-12-14 19:25 ` Eli Zaretskii
2005-12-16 9:04 ` Juri Linkov
2005-12-16 11:29 ` Eli Zaretskii
2005-12-16 12:55 ` Juri Linkov
2005-12-16 13:14 ` Eli Zaretskii
2005-12-16 14:27 ` Juri Linkov
2005-12-16 15:24 ` Eli Zaretskii
2005-12-17 10:54 ` Juri Linkov
2005-12-14 21:25 ` Drew Adams
2005-12-15 4:33 ` Eli Zaretskii
2005-12-13 3:15 ` Richard M. Stallman
2005-12-16 9:05 ` Juri Linkov
2005-12-16 17:40 ` Jan Djärv
2005-12-17 10:47 ` Juri Linkov
2005-12-20 21:55 ` Juri Linkov
2005-12-23 20:43 ` Juri Linkov
2005-12-24 12:15 ` David Reitter
2005-12-24 20:07 ` Juri Linkov
2005-12-24 22:59 ` David Reitter
2005-12-25 16:54 ` Stefan Monnier
2005-12-25 2:51 ` Richard M. Stallman
2005-12-25 6:44 ` Eli Zaretskii
2005-12-26 2:19 ` Richard M. Stallman
2005-12-26 5:06 ` Eli Zaretskii
2005-12-25 9:54 ` David Reitter [this message]
2005-12-26 2:19 ` Richard M. Stallman
2005-12-25 16:58 ` Stefan Monnier
[not found] ` <87x6v29lvv.fsf-monnier+emacs@gnu.org>
2005-12-26 2:20 ` Richard M. Stallman
2005-12-26 16:02 ` Stefan Monnier
2005-12-26 21:56 ` Richard M. Stallman
2005-12-27 19:01 ` Juri Linkov
2005-12-27 19:55 ` Stefan Monnier
2005-12-24 16:32 ` Richard M. Stallman
2005-12-24 20:12 ` Juri Linkov
2005-11-10 19:34 ` Eli Zaretskii
2005-11-10 19:39 ` David Reitter
2005-11-11 8:33 ` Eli Zaretskii
2005-11-12 3:38 ` Richard M. Stallman
2005-11-28 20:23 ` Juri Linkov
2005-11-28 22:17 ` David Reitter
2005-11-28 22:44 ` Juri Linkov
2005-11-29 0:08 ` David Reitter
2005-11-29 9:03 ` Juri Linkov
2005-11-29 9:02 ` Juri Linkov
2005-11-29 3:10 ` Richard M. Stallman
2005-11-29 9:01 ` Juri Linkov
2005-11-29 21:47 ` Richard M. Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=574B84E7-DF6B-4220-BE7E-9AE69AFF135D@gmail.com \
--to=david.reitter@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=juri@jurta.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).