* Re: C-x C-f in two frames -> "user minibuffer while in
@ 2005-07-04 10:01 LENNART BORGMAN
0 siblings, 0 replies; 11+ messages in thread
From: LENNART BORGMAN @ 2005-07-04 10:01 UTC (permalink / raw)
Cc: help-gnu-emacs
From: don provan <dprovan@comcast.net>
> Also, I don't think a single command such as ^x^f can recurse on
> itself, as would be required in the original example. If you ^x^f and
> then switch to another window and do a second ^x^f, as far as I can
> tell, the first ^x^f is always aborted. I think the original poster
> expected to be able to do two file-find's at the same time, one in
> each minibuffer of the two frames.
Would not the behaviour the original poster expected be normal on a windowing system?
^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.2091.1120471829.2857.help-gnu-emacs@gnu.org>]
* Re: C-x C-f in two frames -> "user minibuffer while in [not found] <mailman.2091.1120471829.2857.help-gnu-emacs@gnu.org> @ 2005-07-05 7:12 ` don provan 0 siblings, 0 replies; 11+ messages in thread From: don provan @ 2005-07-05 7:12 UTC (permalink / raw) LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes: > From: don provan <dprovan@comcast.net> > > I think the original poster expected to be able to do two > > file-find's at the same time, one in each minibuffer of the two > > frames. > > Would not the behaviour the original poster expected be normal on a > windowing system? Yes, I suppose it would be, and I'm not sure I'd want to defend Emacs's behavior too strongly. But Emacs is, I would claim, primarily a keyboard entry based editor, so the emphasis is on a single point of data entry rather than visual consistency. So I'm not too distressed by the inconsistency with typical windowing systems, although it wouldn't surprise me if the reasons for being that way are primarily historical. There are some weird and wonderful things going on in the minibuffer, so I wouldn't want to speculate on whether it would be reasonable to approach them differently. -don ^ permalink raw reply [flat|nested] 11+ messages in thread
* C-x C-f in two frames -> "user minibuffer while in minibuffer": Bug? @ 2005-06-08 13:18 David Reitter [not found] ` <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org> 0 siblings, 1 reply; 11+ messages in thread From: David Reitter @ 2005-06-08 13:18 UTC (permalink / raw) I don't know if this is a bug or not, so I'll post it here: If I open a second frame, then do C-x C-f in one of them and press tab so that the window is split and I get a *Completions* buffer in one frame, and when I then select the second frame and do a C-x C-f there, I don't get another *Completions* buffer there, but an error message that appears in the first frame: "Command attempted to use minibuffer while in minibuffer" This happens with standard settings, on the GNU/Linux port as well as on Carbon, no matter what display-buffer-reuse-frames is. Is that a bug? D ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org>]
* Re: C-x C-f in two frames -> "user minibuffer while in [not found] ` <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org> @ 2005-06-08 14:55 ` Toto 2005-07-03 21:47 ` David Combs 0 siblings, 1 reply; 11+ messages in thread From: Toto @ 2005-06-08 14:55 UTC (permalink / raw) In article <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org>, Peter Dyballa <Peter_Dyballa@Web.DE> writes: > Am 08.06.2005 um 15:18 schrieb David Reitter: > >> If I open a second frame, then do C-x C-f in one of them and press tab >> so that the window is split and I get a *Completions* buffer in one >> frame, and when I then select the second frame and do a C-x C-f there, >> I don't get another *Completions* buffer there, but an error message >> that appears in the first frame: >> >> "Command attempted to use minibuffer while in minibuffer" >> > > No, that's definitely no bug! There is in the first frame minibuffer > waiting for your input. And since there is only one such thing, yet, > you can't use it for something different somewhere else. > > I think too it would be a nice enhancement if every frame would have > its own minibuffer. I remember that from time to time I had to use more > than one Emacs running to get things together for an input to > minibuffer (could have sorted this out in scratch buffer -- but then I > would have needed to remember how I made minibuffer awaiting my input > ...) If you set enable-recursive-minibuffers to t it works. (setq enable-recursive-minibuffers t) So that's definitely no bug, indeed. > -- > Greetings > <] > Pete o __o |__ o recumbo > ___o /I -\<, |o \ -\),-% ergo sum! > ___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________ > > > -- [ Toto ] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: C-x C-f in two frames -> "user minibuffer while in 2005-06-08 14:55 ` C-x C-f in two frames -> "user minibuffer while in Toto @ 2005-07-03 21:47 ` David Combs 2005-07-04 0:15 ` Miles Bader [not found] ` <mailman.2058.1120436940.2857.help-gnu-emacs@gnu.org> 0 siblings, 2 replies; 11+ messages in thread From: David Combs @ 2005-07-03 21:47 UTC (permalink / raw) In article <A$E7Qq1ywbQg@ludens>, Toto <bago@ludens.elte.hu> wrote: >In article <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org>, Peter Dyballa <Peter_Dyballa@Web.DE> writes: >> Am 08.06.2005 um 15:18 schrieb David Reitter: >> >>> If I open a second frame, then do C-x C-f in one of them and press tab >>> so that the window is split and I get a *Completions* buffer in one >>> frame, and when I then select the second frame and do a C-x C-f there, >>> I don't get another *Completions* buffer there, but an error message >>> that appears in the first frame: >>> >>> "Command attempted to use minibuffer while in minibuffer" >>> >> >> No, that's definitely no bug! There is in the first frame minibuffer >> waiting for your input. And since there is only one such thing, yet, >> you can't use it for something different somewhere else. >> >> I think too it would be a nice enhancement if every frame would have >> its own minibuffer. I remember that from time to time I had to use more >> than one Emacs running to get things together for an input to >> minibuffer (could have sorted this out in scratch buffer -- but then I >> would have needed to remember how I made minibuffer awaiting my input >> ...) > >If you set enable-recursive-minibuffers to t it works. >(setq enable-recursive-minibuffers t) > >So that's definitely no bug, indeed. > Sounds good -- but if it were good, why isn't "on" the default? That is, what *disadvantages* from setting it on? What bewares of having it on? Thanks, David ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: C-x C-f in two frames -> "user minibuffer while in 2005-07-03 21:47 ` David Combs @ 2005-07-04 0:15 ` Miles Bader [not found] ` <mailman.2058.1120436940.2857.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 11+ messages in thread From: Miles Bader @ 2005-07-04 0:15 UTC (permalink / raw) dkcombs@panix.com (David Combs) writes: >>If you set enable-recursive-minibuffers to t it works. >>(setq enable-recursive-minibuffers t) > > That is, what *disadvantages* from setting it on? What bewares > of having it on? It apparently confuses beginners greatly when they accidentally end up with a recursive minibuffer. For instance, a common scenario is something like: you click the mouse in a buffer while the minibuffer is active, then re-invoke your command thinking the minibuffer input had been aborted [but of course it wasn't, so you end up with recursive minibuffers]. If you have a good mental model of how Emacs works, you'll recognize this situation and deal with it properly, but many people don't. -Miles -- I'd rather be consing. ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.2058.1120436940.2857.help-gnu-emacs@gnu.org>]
* Re: C-x C-f in two frames -> "user minibuffer while in [not found] ` <mailman.2058.1120436940.2857.help-gnu-emacs@gnu.org> @ 2005-07-04 7:52 ` don provan 2005-07-05 22:27 ` Miles Bader [not found] ` <mailman.2259.1120602813.2857.help-gnu-emacs@gnu.org> 2005-07-04 8:23 ` David Kastrup 1 sibling, 2 replies; 11+ messages in thread From: don provan @ 2005-07-04 7:52 UTC (permalink / raw) Miles Bader <miles@gnu.org> writes: > dkcombs@panix.com (David Combs) writes: > >>If you set enable-recursive-minibuffers to t it works. > >>(setq enable-recursive-minibuffers t) > > > > That is, what *disadvantages* from setting it on? What bewares > > of having it on? > > It apparently confuses beginners greatly when they accidentally end up > with a recursive minibuffer. Apparently? You really mean to say it's never confused you? I'm impressed. Anyway, I'm sure that's the main reason. Another reason, I would guess, is that there are a few bugs. Every once in a while, I run into cases where the wrong key map is active or the mini-buffer is prompting for one thing but doing completion for another. But even so, I agree that most experienced Emacs users would probably prefer recursive minibuffers enabled, especially once they get used to it. The original question sounds like the user expected each frame to have its own, independent minibuffer. Even with minibuffers enabled, the minibuffers in each frame are tied together so that, if I understand things correctly, there's really only one recursive stack, and the current top interaction typically attached to the current frame. Also, I don't think a single command such as ^x^f can recurse on itself, as would be required in the original example. If you ^x^f and then switch to another window and do a second ^x^f, as far as I can tell, the first ^x^f is always aborted. I think the original poster expected to be able to do two file-find's at the same time, one in each minibuffer of the two frames. -don ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: C-x C-f in two frames -> "user minibuffer while in 2005-07-04 7:52 ` don provan @ 2005-07-05 22:27 ` Miles Bader [not found] ` <mailman.2259.1120602813.2857.help-gnu-emacs@gnu.org> 1 sibling, 0 replies; 11+ messages in thread From: Miles Bader @ 2005-07-05 22:27 UTC (permalink / raw) don provan <dprovan@comcast.net> writes: >> It apparently confuses beginners greatly when they accidentally end up >> with a recursive minibuffer. > > Apparently? You really mean to say it's never confused you? I'm > impressed. Well of course I occasionally get tripped up, but I usually quickly realize what's going on and fix it. -Miles -- Would you like fries with that? ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <mailman.2259.1120602813.2857.help-gnu-emacs@gnu.org>]
* Re: C-x C-f in two frames -> "user minibuffer while in [not found] ` <mailman.2259.1120602813.2857.help-gnu-emacs@gnu.org> @ 2005-07-07 7:21 ` don provan 2005-07-07 8:57 ` Thien-Thi Nguyen 0 siblings, 1 reply; 11+ messages in thread From: don provan @ 2005-07-07 7:21 UTC (permalink / raw) Miles Bader <miles@gnu.org> writes: > don provan <dprovan@comcast.net> writes: > >> It apparently confuses beginners greatly when they accidentally end up > >> with a recursive minibuffer. > > > > Apparently? You really mean to say it's never confused you? I'm > > impressed. > > Well of course I occasionally get tripped up, but I usually quickly > realize what's going on and fix it. (*whew*) You had me worried, there. I was suspecting you might be an alien invader or something. Anyway, as I say, I agree it's a win. It's just undeniably confusing, not merely "apparently" confusing. Like when you recurse to do a second operation, but then you have to actually do something to get yourself back into the minibuffer to resume -- or even abort! -- the original operation. You have to get very comfortable switching between windows before that seems at all natural. What's more, the minibuffer at times gives you no clue there's previously started command to return to. Has anyone come up with any ways the recursive commands could be better, or is it pretty much accepted that there's nothing that could be done to improve them? -don ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: C-x C-f in two frames -> "user minibuffer while in 2005-07-07 7:21 ` don provan @ 2005-07-07 8:57 ` Thien-Thi Nguyen 2005-07-07 15:10 ` Drew Adams 0 siblings, 1 reply; 11+ messages in thread From: Thien-Thi Nguyen @ 2005-07-07 8:57 UTC (permalink / raw) don provan <dprovan@comcast.net> writes: > Has anyone come up with any ways the recursive commands could be > better, or is it pretty much accepted that there's nothing that could > be done to improve them? one idea is to modify `mode-line-format' to indicate presence, level, or stack contents, of recursion. presence: R level: RRR (or maybe R3) stack contents: (find-file find-file find-file) alternatively, borrow something from the recursive editing indicator (normally square braces around the major and minor mode info). nothing is univerally "pretty much accepted" (except death and taxes, but i hear emacs and the fsf avoid these, respectively, somehow :-). thi ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: C-x C-f in two frames -> "user minibuffer while in 2005-07-07 8:57 ` Thien-Thi Nguyen @ 2005-07-07 15:10 ` Drew Adams 0 siblings, 0 replies; 11+ messages in thread From: Drew Adams @ 2005-07-07 15:10 UTC (permalink / raw) > Has anyone come up with any ways the recursive commands could be > better, or is it pretty much accepted that there's nothing that could > be done to improve them? one idea is to modify `mode-line-format' to indicate presence, level, or stack contents, of recursion. presence: R level: RRR (or maybe R3) stack contents: (find-file find-file find-file) alternatively, borrow something from the recursive editing indicator (normally square braces around the major and minor mode info). One problem is that such mode-line changes are not very noticeable. Now that we can easily change the mode-line face, that could be used to draw more attention to a recursive edit. Face change, especially background, is more noticeable than simply adding/changing mode-line text, and if the color-change is well chosen, it need not be intrusive/annoying. I do something similar: change the minibuffer (not the mode-line) background. Library `oneonone.el' (http://www.emacswiki.org/elisp/oneonone.el) sets up a dedicated minibuffer frame, and that frame's background is changed dynamically to indicate the current state. There are 3 states: normal (inactive), awaiting user input (active), and isearch (searching). There is no state specifically for recursive edit (but there could be); recursive edit is reflected by the "active" state. "Active" essentially means "not top-level". See http://www.emacswiki.org/cgi-bin/wiki/Dedicated_Minibuffer_Frame for an explanation and screenshots. Whenever you are in a recursive edit, not only does the mode-line indicate this (by surrounding the mode name with brackets, as usual: []), but the minibuffer frame background color is also changed to indicate the "active" mode. You normally only see this color minibuffer when Emacs is expecting input, so, if you continue to see it, it acts as a clue to look for the brackets in the mode-line that indicate a recursive edit. HTH, Drew. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: C-x C-f in two frames -> "user minibuffer while in [not found] ` <mailman.2058.1120436940.2857.help-gnu-emacs@gnu.org> 2005-07-04 7:52 ` don provan @ 2005-07-04 8:23 ` David Kastrup 1 sibling, 0 replies; 11+ messages in thread From: David Kastrup @ 2005-07-04 8:23 UTC (permalink / raw) Miles Bader <miles@gnu.org> writes: > dkcombs@panix.com (David Combs) writes: >>>If you set enable-recursive-minibuffers to t it works. >>>(setq enable-recursive-minibuffers t) >> >> That is, what *disadvantages* from setting it on? What bewares >> of having it on? > > It apparently confuses beginners greatly when they accidentally end up > with a recursive minibuffer. > > For instance, a common scenario is something like: you click the mouse > in a buffer while the minibuffer is active, then re-invoke your command > thinking the minibuffer input had been aborted [but of course it wasn't, > so you end up with recursive minibuffers]. If you have a good mental > model of how Emacs works, you'll recognize this situation and deal with > it properly, but many people don't. Most common problem for me is M-x M-x accidentally (probably by autorepeat). Getting out of those can be fun, in particularly if you change windows manually afterwards (Esc Esc Esc helps somewhat for that case). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-07-07 15:10 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-07-04 10:01 C-x C-f in two frames -> "user minibuffer while in LENNART BORGMAN [not found] <mailman.2091.1120471829.2857.help-gnu-emacs@gnu.org> 2005-07-05 7:12 ` don provan -- strict thread matches above, loose matches on Subject: below -- 2005-06-08 13:18 C-x C-f in two frames -> "user minibuffer while in minibuffer": Bug? David Reitter [not found] ` <mailman.3863.1118240186.25862.help-gnu-emacs@gnu.org> 2005-06-08 14:55 ` C-x C-f in two frames -> "user minibuffer while in Toto 2005-07-03 21:47 ` David Combs 2005-07-04 0:15 ` Miles Bader [not found] ` <mailman.2058.1120436940.2857.help-gnu-emacs@gnu.org> 2005-07-04 7:52 ` don provan 2005-07-05 22:27 ` Miles Bader [not found] ` <mailman.2259.1120602813.2857.help-gnu-emacs@gnu.org> 2005-07-07 7:21 ` don provan 2005-07-07 8:57 ` Thien-Thi Nguyen 2005-07-07 15:10 ` Drew Adams 2005-07-04 8:23 ` David Kastrup
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.