* Usage examples of dedicated windows and popup frames? @ 2011-07-08 14:19 Tassilo Horn 2011-07-08 14:47 ` Richard Riley ` (3 more replies) 0 siblings, 4 replies; 26+ messages in thread From: Tassilo Horn @ 2011-07-08 14:19 UTC (permalink / raw) To: emacs-devel Hi all, my probably most frequently used emacs keys are `ESC ESC ESC' and `C-x b' which somehow suggests that I might want to improve my window/frame management. Since lately I've read of many people on this list that they are using dedicated windows, dedicated minibuffer frames, and popup frames. I've briefly checked the docs. Well, that explains all variables and functions, but it doesn't really help finding some appealing overall configuration that just works for me. As a self-experiment, I've just evaluated (setq pop-up-frames 'graphic-only display-buffer-reuse-frames t) in *scratch* to try out something completely different from the default behavior. And basically I it's not that bad. But after using it for an hour, I have more than 10 open emacs frames now. Most of them were opened for showing completion possibilities, but after I've finished completion they became useless. It would be great if those would be closed automagically... Long story short: it would be nice if some people with non-standard window/frame settings could share and briefly explain their configuration. I'm very interested. And maybe it's a good idea to ship emacs with some predefined setups users can easily try out and then extend to find one that suits them best, for example, the current default window oriented configuration, a more frame oriented configuration, and a frame oriented configuration with a dedicated minibuffer frame, too. Bye, Tassilo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-08 14:19 Usage examples of dedicated windows and popup frames? Tassilo Horn @ 2011-07-08 14:47 ` Richard Riley 2011-07-08 14:49 ` John Yates ` (2 subsequent siblings) 3 siblings, 0 replies; 26+ messages in thread From: Richard Riley @ 2011-07-08 14:47 UTC (permalink / raw) To: emacs-devel Tassilo Horn <tassilo@member.fsf.org> writes: > Hi all, > > my probably most frequently used emacs keys are `ESC ESC ESC' and `C-x > b' which somehow suggests that I might want to improve my window/frame > management. > > Since lately I've read of many people on this list that they are using > dedicated windows, dedicated minibuffer frames, and popup frames. I've > briefly checked the docs. Well, that explains all variables and > functions, but it doesn't really help finding some appealing overall > configuration that just works for me. > > As a self-experiment, I've just evaluated > > (setq pop-up-frames 'graphic-only > display-buffer-reuse-frames t) > > in *scratch* to try out something completely different from the default > behavior. And basically I it's not that bad. But after using it for an > hour, I have more than 10 open emacs frames now. Most of them were > opened for showing completion possibilities, but after I've finished > completion they became useless. It would be great if those would be > closed automagically... > > Long story short: it would be nice if some people with non-standard > window/frame settings could share and briefly explain their > configuration. I'm very interested. > > And maybe it's a good idea to ship emacs with some predefined setups > users can easily try out and then extend to find one that suits them > best, for example, the current default window oriented configuration, a > more frame oriented configuration, and a frame oriented configuration > with a dedicated minibuffer frame, too. Have a look at Icicles too .... ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-08 14:19 Usage examples of dedicated windows and popup frames? Tassilo Horn 2011-07-08 14:47 ` Richard Riley @ 2011-07-08 14:49 ` John Yates 2011-07-08 16:11 ` Stefan Monnier 2011-07-08 16:11 ` Drew Adams 3 siblings, 0 replies; 26+ messages in thread From: John Yates @ 2011-07-08 14:49 UTC (permalink / raw) To: emacs-devel On Fri, Jul 8, 2011 at 10:19 AM, Tassilo Horn <tassilo@member.fsf.org> wrote: > Long story short: it would be nice if some people with non-standard > window/frame settings could share and briefly explain their > configuration. I'm very interested. Me too! > And maybe it's a good idea to ship emacs with some predefined setups > users can easily try out and then extend to find one that suits them > best, for example, the current default window oriented configuration, a > more frame oriented configuration, and a frame oriented configuration > with a dedicated minibuffer frame, too. Yes please! /john ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-08 14:19 Usage examples of dedicated windows and popup frames? Tassilo Horn 2011-07-08 14:47 ` Richard Riley 2011-07-08 14:49 ` John Yates @ 2011-07-08 16:11 ` Stefan Monnier 2011-07-08 16:34 ` Drew Adams 2011-07-08 17:54 ` Tassilo Horn 2011-07-08 16:11 ` Drew Adams 3 siblings, 2 replies; 26+ messages in thread From: Stefan Monnier @ 2011-07-08 16:11 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel > (setq pop-up-frames 'graphic-only > display-buffer-reuse-frames t) > in *scratch* to try out something completely different from the default > behavior. And basically I it's not that bad. But after using it for an > hour, I have more than 10 open emacs frames now. Most of them were > opened for showing completion possibilities, but after I've finished > completion they became useless. It would be great if those would be > closed automagically... "They" should be iconified automatically and only one frame should be (re-)used for *Completions*. Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Usage examples of dedicated windows and popup frames? 2011-07-08 16:11 ` Stefan Monnier @ 2011-07-08 16:34 ` Drew Adams 2011-07-08 16:51 ` Stefan Monnier 2011-07-08 17:54 ` Tassilo Horn 1 sibling, 1 reply; 26+ messages in thread From: Drew Adams @ 2011-07-08 16:34 UTC (permalink / raw) To: 'Stefan Monnier', 'Tassilo Horn'; +Cc: emacs-devel > > I have more than 10 open emacs frames now. Most of them were > > opened for showing completion possibilities, but after I've finished > > completion they became useless. It would be great if those would be > > closed automagically... > > "They" should be iconified automatically and only one frame should be > (re-)used for *Completions*. What happens to the frame should be under _user_ control. At least it should be possible to choose frame deletion rather than iconification. On MS Windows, at least, iconifying is more or less animated: you see the frame zip down to the task bar, and that's annoying if it happens all the time. When a frame is deleted, OTOH, it simply disappears immediately - poof! And it is normally the case that I (at least) do not _want_ to have such frames among those iconified - ever. Useless clutter. In Windows, you get an icon in the task bar for Emacs, and clicking it pops up a list (menu) of all of the iconified frames. There's no way I want to see *Completions* (or any other frame I'm done with) in this list. *Completions* is for temporary display. I would never pick *Completions* in the menu of iconified frames to raise it. I hardly ever want to access *Completions* outside of the minibuffer dialog, and whenever I do (e.g. to copy its text from the last dialog for some purpose) I just use `C-x C-b'. At least for me, on MS Windows, I want the *Completions* frame deleted, never iconified. So "should be iconified" is a non-starter here, for me. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-08 16:34 ` Drew Adams @ 2011-07-08 16:51 ` Stefan Monnier 2011-07-08 17:38 ` Drew Adams 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2011-07-08 16:51 UTC (permalink / raw) To: Drew Adams; +Cc: 'Tassilo Horn', emacs-devel >> > I have more than 10 open emacs frames now. Most of them were >> > opened for showing completion possibilities, but after I've finished >> > completion they became useless. It would be great if those would be >> > closed automagically... >> "They" should be iconified automatically and only one frame should be >> (re-)used for *Completions*. > What happens to the frame should be under _user_ control. At least it > should be possible to choose frame deletion rather than iconification. I know, Drew. You've made your point obnoxiously clear several times already. But here, I'm talking about "the current intended default behavior", i.e. that which decides whether what he sees in his default config is a bug or not. I.e. unrelated to your rant. Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Usage examples of dedicated windows and popup frames? 2011-07-08 16:51 ` Stefan Monnier @ 2011-07-08 17:38 ` Drew Adams 0 siblings, 0 replies; 26+ messages in thread From: Drew Adams @ 2011-07-08 17:38 UTC (permalink / raw) To: 'Stefan Monnier'; +Cc: 'Tassilo Horn', emacs-devel > >> "They" should be iconified automatically and only one > >> frame should be (re-)used for *Completions*. > > > What happens to the frame should be under _user_ control. > > At least it should be possible to choose frame deletion > > rather than iconification. > > I know, Drew. You've made your point obnoxiously clear > several times already. ... your rant. Huh? What rant? What's obnoxious about explaining the situation on Windows? You and I have discussed automatic frame iconifying in the context of Emacs bug reports involving `bury-buffer', but AFAIK automatic frame iconifying has never come up on emacs-devel (even in the context of `bury-buffer'). And although you have argued (in bug threads) that `bury-buffer' should iconify the frame, this is the first time (AFAIK) that you have stated that a *Completions* frame "should be iconified". A fortiori, it is the first time I have responded to such a proposal - anywhere, obnoxiously or otherwise. Besides, AFAIK, nowhere (neither here nor in a bug thread) have I mentioned before the second annoyance from iconifying: that of adding to the Emacs list/menu in the Windows task bar. Until now, IIRC, I have mentioned (to you, not emacs-devel) only the annoyance of the Windows iconifying animation, not the task-bar list/menu annoyance. > But here, I'm talking about "the current intended default > behavior" I see. I didn't know that was the current intended behavior for *Completions* with non-nil `pop-up-frames' (having never seen it in any Emacs version), and I didn't realize that's all you were saying. I thought you were saying that this is what you think _should_ happen in the future - a proposal as the proper fix for the problem Tassilo reported, and not just a description of the currently intended behavior. Ambiguity of English "should". When you argued that `bury-buffer' "should" hard-code iconify a dedicated frame you did mean more than just "that's what the current design is" - you argued in favor of that approach. I thought that's what you were doing here too: proposing iconifying as the solution to the *Completions* frame problem. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-08 16:11 ` Stefan Monnier 2011-07-08 16:34 ` Drew Adams @ 2011-07-08 17:54 ` Tassilo Horn 2011-07-08 18:55 ` Stefan Monnier 1 sibling, 1 reply; 26+ messages in thread From: Tassilo Horn @ 2011-07-08 17:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: Hi Stefan, >> (setq pop-up-frames 'graphic-only >> display-buffer-reuse-frames t) >> >> Most of them were opened for showing completion possibilities, but >> after I've finished completion they became useless. It would be >> great if those would be closed automagically... > > "They" should be iconified automatically and only one frame should be > (re-)used for *Completions*. Hm, not what I get. With emacs -Q updated yesterday: 1. Goto *scratch* and eval the form above. 2. (def<TAB> ==> a comletion frame pops up *and gets input focus* 3. C-x 5 o to get back to the original frame 4. (defalia<TAB> ==> defalias is the sole completion, and at that point in time, the completion frame shows *scratch*, too, just like the frame I'm typing in. Oh, now I did another completion, and this time the completion frame was indeed iconified. Unfortunately, it doesn't come up automatically when completing again. Doing it manually shows that it contains the new completion list. Another annoyance (but not Emacs' fault) is that the usability highly depends on the window manager. Here, using GNOME3 the window placement is not that advanced. The popup frames often appear on top of the emacs frame I'm typing in. So decided to use pop-up-frames by default, but keep completion and other temporary stuff (buffers starting/ending with *) in the current frame: (setq pop-up-frames 'graphic-only display-buffer-reuse-frames t special-display-regexps '(("^\\*.*\\*$" pop-to-buffer-same-frame))) Using that (emacs -Q), completion now pops up a new window showing *Completions*, and also a new frame showing the same buffer... If I understand the docs correctly, then I could also use (setq special-display-regexps '(("^\\*.*\\*$" ((same-frame . t))))) but with that, completions still appear in a popup frame and no popup window is shown at all. Bye, Tassilo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-08 17:54 ` Tassilo Horn @ 2011-07-08 18:55 ` Stefan Monnier 2011-07-09 13:00 ` martin rudalics 0 siblings, 1 reply; 26+ messages in thread From: Stefan Monnier @ 2011-07-08 18:55 UTC (permalink / raw) To: Tassilo Horn; +Cc: emacs-devel > Hm, not what I get. With emacs -Q updated yesterday: > 1. Goto *scratch* and eval the form above. > 2. (def<TAB> ==> a comletion frame pops up *and gets input focus* This input focus issue is a problem, indeed, but AFAIK it's one that's difficult to fix. > 4. (defalia<TAB> ==> defalias is the sole completion, and at that point > in time, the completion frame shows *scratch*, too, just like the > frame I'm typing in. This is clearly a bug. Martin, could you take a look at it? If we just popped up this frame for *Completions*, minibuffer-hide-completions should hide the frame. > Oh, now I did another completion, and this time the completion frame was > indeed iconified. Huh? > Unfortunately, it doesn't come up automatically when completing again. > Doing it manually shows that it contains the new completion list. Yet another bug. > (setq pop-up-frames 'graphic-only > display-buffer-reuse-frames t > special-display-regexps '(("^\\*.*\\*$" pop-to-buffer-same-frame))) > > Using that (emacs -Q), completion now pops up a new window showing > *Completions*, and also a new frame showing the same buffer... > If I understand the docs correctly, then I could also use > > (setq special-display-regexps '(("^\\*.*\\*$" ((same-frame . t))))) > > but with that, completions still appear in a popup frame and no popup > window is shown at all. Martin, can you explain this behavior? Stefan ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-08 18:55 ` Stefan Monnier @ 2011-07-09 13:00 ` martin rudalics 2011-07-09 15:03 ` Drew Adams 2011-07-09 17:22 ` Usage examples of dedicated windows and popup frames? Tassilo Horn 0 siblings, 2 replies; 26+ messages in thread From: martin rudalics @ 2011-07-09 13:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: Tassilo Horn, emacs-devel >> 1. Goto *scratch* and eval the form above. >> 2. (def<TAB> ==> a comletion frame pops up *and gets input focus* > > This input focus issue is a problem, indeed, but AFAIK it's one that's > difficult to fix. Drew uses `redirect-frame-focus' and from what I can tell after experimenting a bit with his code it seems to work. >> 4. (defalia<TAB> ==> defalias is the sole completion, and at that point >> in time, the completion frame shows *scratch*, too, just like the >> frame I'm typing in. > > This is clearly a bug. Martin, could you take a look at it? If we just > popped up this frame for *Completions*, minibuffer-hide-completions > should hide the frame. > >> Oh, now I did another completion, and this time the completion frame was >> indeed iconified. > > Huh? > >> Unfortunately, it doesn't come up automatically when completing again. >> Doing it manually shows that it contains the new completion list. > > Yet another bug. > >> (setq pop-up-frames 'graphic-only >> display-buffer-reuse-frames t >> special-display-regexps '(("^\\*.*\\*$" pop-to-buffer-same-frame))) >> >> Using that (emacs -Q), completion now pops up a new window showing >> *Completions*, and also a new frame showing the same buffer... >> If I understand the docs correctly, then I could also use >> >> (setq special-display-regexps '(("^\\*.*\\*$" ((same-frame . t))))) >> >> but with that, completions still appear in a popup frame and no popup >> window is shown at all. > > Martin, can you explain this behavior? Yes. I sometimes used the symbol 'dedicated instead of 'dedicate so the *Completions* window did not get softly dedicated. Should be fixed now. Tassilo please tell us what you see now in your cases. martin ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Usage examples of dedicated windows and popup frames? 2011-07-09 13:00 ` martin rudalics @ 2011-07-09 15:03 ` Drew Adams 2011-07-10 0:43 ` chad 2011-07-10 23:45 ` undisplay temporary dialog buffers when done [was: ... dedicated windows and popup frames] Drew Adams 2011-07-09 17:22 ` Usage examples of dedicated windows and popup frames? Tassilo Horn 1 sibling, 2 replies; 26+ messages in thread From: Drew Adams @ 2011-07-09 15:03 UTC (permalink / raw) To: 'martin rudalics', 'Stefan Monnier' Cc: 'Tassilo Horn', emacs-devel > >> 1. Goto *scratch* and eval the form above. > >> 2. (def<TAB> ==> a comletion frame pops up *and gets input focus* > > > > This input focus issue is a problem, indeed, but AFAIK > > it's one that's difficult to fix. > > Drew uses `redirect-frame-focus' and from what I can tell after > experimenting a bit with his code it seems to work. Yes, but I do that explicitly as part of my setup, and only for the `*Completions*' frame. I know ahead of time that Emacs will use buffer `*Completions*', and I know that its input focus should be redirected to the minibuffer frame (by default). But as I mentioned, there are occasionally some other frames that pop up in a context where the focus should remain in the minibuffer. In my case, buffers named `*...*' are special-display (dedicated), so they pop up in separate frames. Only rarely is such a buffer used as part of a dialog, but it can happen, breaking the necessary input focus. Some such pop-up frames are in fact for completion. Some vanilla and 3rd-party Emacs code uses completion with a buffer other than `*Completions*'. Nothing inherently wrong with that, but it thus steps outside my workaround of redirecting the `*Completions*' frame focus to the minibuffer frame. For instance, after `M-e' in Isearch, `M-TAB' completes, and if there is more than one candidate then it pops up buffer `*Isearch completions*' (not `*Completions*'). Since that buffer name matches my `special-display-regexps', it gets a separate, dedicated frame. And when the new frame is created Windows gives it the focus, taking the focus away from the minibuffer frame. Without some extra, workaround coding for such a case the user needs to click the minibuffer frame to get the focus back where it belongs. And obviously a user cannot really special-code or customize to deal with each such pop-up frame that might arise. Nothing prevents a library (vanilla or otherwise) from popping up a buffer whose name matches `special-display-regexps', including for completion or another context where the focus should not move to another frame. And then there's the problem of removing that popped-up frame when the dialog is finished. Similarly, there I can foresee the problem in the case of `*Completions*' and handle it specially (knowing the completion dialog). Not so in the general case (unknown). Again, in practice there are only very few such pop-up dialog frames, other than `*Completions*'. But there is still a general problem, even if it is rare because I've taken care of it for the main case (`*Completions*'). I know that you know all of this already. Just mentioning it to complete the thread info a bit. Perhaps we could add a way for code to indicate that it is displaying a given buffer only for the purpose and duration of a user dialog, and thus: a. For that duration the buffer's frame (if separate) would have its input focus redirected to the minibuffer's frame. b. After the dialog finishes, the buffer's frame (if separate) would be deleted. E.g., something like: (with-dialog-buffer BUF ...) Perhaps something like that could be a way to handle the general case (providing that coders actually used it). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-09 15:03 ` Drew Adams @ 2011-07-10 0:43 ` chad 2011-07-10 9:00 ` martin rudalics 2011-07-10 9:43 ` Drew Adams 2011-07-10 23:45 ` undisplay temporary dialog buffers when done [was: ... dedicated windows and popup frames] Drew Adams 1 sibling, 2 replies; 26+ messages in thread From: chad @ 2011-07-10 0:43 UTC (permalink / raw) To: Drew Adams Cc: 'martin rudalics', 'Tassilo Horn', 'Stefan Monnier', emacs-devel Do you take special steps with the Ediff frame? That's the other problem case I'm seeing with multiple frames and focus on Windows/MacOSX. *Chad ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-10 0:43 ` chad @ 2011-07-10 9:00 ` martin rudalics 2011-07-10 9:43 ` Drew Adams 1 sibling, 0 replies; 26+ messages in thread From: martin rudalics @ 2011-07-10 9:00 UTC (permalink / raw) To: chad Cc: 'Tassilo Horn', 'Stefan Monnier', Drew Adams, emacs-devel > Do you take special steps with the Ediff frame? That's the other > problem case I'm seeing with multiple frames and focus on > Windows/MacOSX. Ediff frames are hand tailored using a custom split-window-function and other layout management techniques. Which problems do you see? martin ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Usage examples of dedicated windows and popup frames? 2011-07-10 0:43 ` chad 2011-07-10 9:00 ` martin rudalics @ 2011-07-10 9:43 ` Drew Adams 2011-07-12 17:47 ` chad 1 sibling, 1 reply; 26+ messages in thread From: Drew Adams @ 2011-07-10 9:43 UTC (permalink / raw) To: 'chad' Cc: 'martin rudalics', 'Tassilo Horn', 'Stefan Monnier', emacs-devel > Do you take special steps with the Ediff frame? That's the > other problem case I'm seeing with multiple frames and focus > on Windows/MacOSX. No, I don't think so. Well, maybe - I use an old file ediff+.el, but it doesn't seem to have anything in it related to frames. I doubt it's relevant here. I had forgotten that I even used it, to tell the truth. http://www.emacswiki.org/emacs/download/ediff%2b.el I typically use `ediff-buffers'. In my setup (non-nil `pop-up-frames' etc.), each of the two buffers is typically in its own frame; those (portrait) frames are side by side; and the Ediff Control Panel (buffer `Ediff') is a separate (tiny) frame. You didn't say what kinds of problems you see. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-10 9:43 ` Drew Adams @ 2011-07-12 17:47 ` chad 2011-07-12 18:55 ` Drew Adams 2011-07-13 6:24 ` martin rudalics 0 siblings, 2 replies; 26+ messages in thread From: chad @ 2011-07-12 17:47 UTC (permalink / raw) To: Drew Adams Cc: 'martin rudalics', 'Tassilo Horn', 'Stefan Monnier', emacs-devel [-- Attachment #1: Type: text/plain, Size: 922 bytes --] On Jul 10, 2011, at 2:43 AM, Drew Adams wrote: >> Do you take special steps with the Ediff frame? That's the >> other problem case I'm seeing with multiple frames and focus >> on Windows/MacOSX. > > [...] > > I typically use `ediff-buffers'. In my setup (non-nil `pop-up-frames' etc.), > each of the two buffers is typically in its own frame; those (portrait) frames > are side by side; and the Ediff Control Panel (buffer `Ediff') is a separate > (tiny) frame. > > You didn't say what kinds of problems you see. Sorry; I didn't mean to sound like I was reporting a bug as much as an uncomfortable system interaction. My primary problem with ediff is the Ediff Control Panel; I find that I have to manually give it focus after almost every operation. I was wondering if anyone had worked out a way around this annoyance on click-to-focus systems like Windows and MacOSX. Thanks, *Chad [-- Attachment #2: Type: text/html, Size: 1489 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Usage examples of dedicated windows and popup frames? 2011-07-12 17:47 ` chad @ 2011-07-12 18:55 ` Drew Adams 2011-07-13 6:24 ` martin rudalics 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2011-07-12 18:55 UTC (permalink / raw) To: 'chad' Cc: 'martin rudalics', 'Tassilo Horn', 'Stefan Monnier', emacs-devel > My primary problem with ediff is the Ediff Control Panel; > I find that I have to manually give it focus after almost every > operation. Do you mean ediff operation here? If so, I don't see that. As long as I continue to hit keys in the control panel window (frame), it keeps the focus. (This is using my own setup, with `pop-up-frames' non-nil etc.) > I was wondering if anyone had worked out a way around this > annoyance on click-to-focus systems like Windows I am using Windows, but either I don't see what you see or I don't understand what you see. Perhaps give a recipe, if possible starting from emacs -Q, so we can be sure what behavior you mean to describe. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-12 17:47 ` chad 2011-07-12 18:55 ` Drew Adams @ 2011-07-13 6:24 ` martin rudalics 2011-07-13 23:09 ` chad 1 sibling, 1 reply; 26+ messages in thread From: martin rudalics @ 2011-07-13 6:24 UTC (permalink / raw) To: chad Cc: 'Tassilo Horn', 'Stefan Monnier', Drew Adams, emacs-devel > My primary problem with ediff is > the Ediff Control Panel; I find that I have to manually give it focus > after almost every operation. I was wondering if anyone had worked out > a way around this annoyance on click-to-focus systems like Windows > and MacOSX. I can't observe that behavior here. Do you mean that, for example, after typing `n' in the control panel, focus switches to one of the windows showing a buffer you're diffing? martin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-13 6:24 ` martin rudalics @ 2011-07-13 23:09 ` chad 0 siblings, 0 replies; 26+ messages in thread From: chad @ 2011-07-13 23:09 UTC (permalink / raw) To: martin rudalics, Drew Adams; +Cc: Emacs devel On Jul 12, 2011, at 11:24 PM, martin rudalics wrote: > I can't observe that behavior here. Do you mean that, for example, > after typing `n' in the control panel, focus switches to one of the > windows showing a buffer you're diffing? I do mean that, but I can't now reproduce it with -Q, so I think I have myself to blame. Sorry for wasting all your time. *Chad ^ permalink raw reply [flat|nested] 26+ messages in thread
* undisplay temporary dialog buffers when done [was: ... dedicated windows and popup frames] 2011-07-09 15:03 ` Drew Adams 2011-07-10 0:43 ` chad @ 2011-07-10 23:45 ` Drew Adams 1 sibling, 0 replies; 26+ messages in thread From: Drew Adams @ 2011-07-10 23:45 UTC (permalink / raw) To: 'martin rudalics', 'Stefan Monnier' Cc: 'Tassilo Horn', emacs-devel For code that temporarily displays a buffer for the duration of a user-input dialog, I suggested that we might wrap that code, so that when the dialog is finished the buffer's display disappears: it is undisplayed as part of unwinding the dialog. This pertains to buffer displays such as *Completions* and the Dired marked-files list (e.g. when you delete, copy, etc. files). Such buffers are popped up in a window that might be dedicated, in a separate frame, etc., depending on user settings. We generally want to get rid of the buffer's display in such cases. This was the suggestion: > Perhaps we could add a way for code to indicate that it is > displaying a given buffer only for the purpose and duration > of a user dialog, and thus: > > a. For that duration the buffer's frame (if separate) would > have its input focus redirected to the minibuffer's frame. > b. After the dialog finishes, the buffer's frame (if > separate) would be deleted. > > E.g., something like: (with-dialog-buffer BUF ...) > Perhaps something like that could be a way to handle the > general case (providing that coders actually used it). This approach gives the code that carries out the user-input dialog and displays the supporting information buffer the responsibility and possibility of making that buffer disappear when the dialog is over. IOW, it keeps control over such behavior local to where it is needed. Here is an example of what I meant by such a macro (not tested much). Instead of `with-dialog-buffer' I named it `undisplay-on-unwind'. It need not be associated with dialog code, but that is probably the typical case. (defmacro undisplay-on-unwind (buffer &rest body) "Undisplay BUFFER after evaluating BODY. If BUFFER is not shown in the selected window or `minibuffer-selected-window', then bury BUFFER (`bury-buffer') and delete all windows showing it, if possible. Use this in particular when BODY pops up BUFFER as part of a temporary dialog and there is no need to show BUFFER after the dialog is finished." (let ((buf (make-symbol "buf"))) `(unwind-protect (progn ,@body) (let ((,buf ,buffer)) (when (bufferp ,buf) (setq ,buf (buffer-name ,buf))) (when (stringp ,buf) (let ((swin (selected-window))) ;; Do nothing if BUFFER is in the selected window ;; or the minibuffer window is selected now ;; and BUFFER's window was selected just before. (when (window-minibuffer-p swin) (setq swin (minibuffer-selected-window))) (when (and (get-buffer-window ,buf 'visible) (window-live-p swin) ; Needed? (not (eq (window-buffer swin) (get-buffer ,buf)))) ;; Ignore, in particular, "Attempt to delete ;; the sole visible or iconified frame". (ignore-errors (delete-windows-on ,buf)) (bury-buffer (get-buffer ,buf))))))))) This is adapted from part of how I treat `*Completions*' in Icicles. The point here is to give an idea of what such a macro might be - I don't argue that this particular implementation is necessarily correct, complete, what we want, etc. The idea is to couple (a) the display of a buffer whose only purpose is to provide info for some input dialog with (b) that dialog. The BODY for the macro would typically be code that displays BUFFER and asks for some user input. After that dialog is finished, we remove all display of BUFFER. You can try it a bit. E.g.: (defun bar (f1 &optional f2) (let ((foo (get-buffer-create "*FOO*"))) (with-current-buffer foo (erase-buffer)(insert "HHHHHHHHHHHHHHHHHHHHHHHHHHHH")) (funcall f1 foo) (when f2 (save-selected-window (select-window (get-buffer-window "*FOO*" 'visible)) (funcall f2 foo)))) (redisplay t)(sleep-for 3)) ;; 1. Show *FOO* in a separate window (by default). (undisplay-on-unwind "*FOO*" (bar 'display-buffer)) ;; 2. Like previous, but with *FOO* in a separate frame. (undisplay-on-unwind "*FOO*" (bar 'display-buffer-other-frame)) Those two represent the typical case, but we can imagine that `*FOO*' might be displayed in more than one window. ;; 3. Like previous, but two *FOO*s, one in a separate frame. (undisplay-on-unwind "*FOO*" (bar 'display-buffer 'display-buffer-other-frame)) ;; 4. Like previous, but won't delete the frame ;; from `make-frame-command'. (undisplay-on-unwind "*FOO*" (bar 'display-buffer '(lambda (f) (make-frame-command)))) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-09 13:00 ` martin rudalics 2011-07-09 15:03 ` Drew Adams @ 2011-07-09 17:22 ` Tassilo Horn 2011-07-10 9:00 ` martin rudalics 1 sibling, 1 reply; 26+ messages in thread From: Tassilo Horn @ 2011-07-09 17:22 UTC (permalink / raw) To: martin rudalics; +Cc: Stefan Monnier, emacs-devel martin rudalics <rudalics@gmx.at> writes: Hi Martin, > Yes. I sometimes used the symbol 'dedicated instead of 'dedicate so > the *Completions* window did not get softly dedicated. Should be > fixed now. > > Tassilo please tell us what you see now in your cases. Using (setq pop-up-frames 'graphic-only display-buffer-reuse-frames t) the frame showing *Completions* still receives input focus when it shows up the first time. After the completion finished, the frame gets iconified. But it still won't be raised at the next completion. Bye, Tassilo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-09 17:22 ` Usage examples of dedicated windows and popup frames? Tassilo Horn @ 2011-07-10 9:00 ` martin rudalics 2011-07-10 9:39 ` Tassilo Horn 0 siblings, 1 reply; 26+ messages in thread From: martin rudalics @ 2011-07-10 9:00 UTC (permalink / raw) To: Tassilo Horn; +Cc: Stefan Monnier, emacs-devel > Using > > (setq pop-up-frames 'graphic-only > display-buffer-reuse-frames t) > > the frame showing *Completions* still receives input focus when it shows > up the first time. A frame always receives input focus when it shows up the first time. But we can try to redirect focus to the original frame afterwards. > After the completion finished, the frame gets > iconified. But it still won't be raised at the next completion. It's raised here so that's probably a problem with your window manager. I recall someone reporting a similar problem (and that's, after all, the issue causing the introduction of `display-buffer-reuse-frames' IIUC). Does `raise-frame' otherwise DTRT on your system for an iconifed frame? Maybe we could make the *Completions* frame (optionally) invisible instead of iconfying it? martin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-10 9:00 ` martin rudalics @ 2011-07-10 9:39 ` Tassilo Horn 2011-07-10 15:30 ` martin rudalics 0 siblings, 1 reply; 26+ messages in thread From: Tassilo Horn @ 2011-07-10 9:39 UTC (permalink / raw) To: martin rudalics; +Cc: Stefan Monnier, emacs-devel martin rudalics <rudalics@gmx.at> writes: Hi Martin, >> Using >> >> (setq pop-up-frames 'graphic-only >> display-buffer-reuse-frames t) >> >> the frame showing *Completions* still receives input focus when it >> shows up the first time. > > A frame always receives input focus when it shows up the first time. > But we can try to redirect focus to the original frame afterwards. That would be good. >> After the completion finished, the frame gets iconified. But it >> still won't be raised at the next completion. > > It's raised here so that's probably a problem with your window > manager. Possibly. As I said, I use GNOME3, and there minimizing/iconifying is a deprecated concept (you cannot do it with the default configuration). > I recall someone reporting a similar problem (and that's, after all, > the issue causing the introduction of `display-buffer-reuse-frames' > IIUC). Does `raise-frame' otherwise DTRT on your system for an > iconifed frame? I tried with 2 frames, one being iconified (raise-frame (cadr (frame-list))) but that didn't raise the other frame. I made sure that (cadr ...) is indeed the iconified frame. However, `other-frame' raises and selects correctly. > Maybe we could make the *Completions* frame (optionally) invisible > instead of iconfying it? What's "invisible" in this respect? (In any case, I'd try it out.) Bye, Tassilo ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-10 9:39 ` Tassilo Horn @ 2011-07-10 15:30 ` martin rudalics 2011-07-10 16:00 ` Tassilo Horn 0 siblings, 1 reply; 26+ messages in thread From: martin rudalics @ 2011-07-10 15:30 UTC (permalink / raw) To: Tassilo Horn; +Cc: Stefan Monnier, emacs-devel > However, `other-frame' raises and selects correctly. Does `pop-to-buffer-other-frame' raise and select correctly when the buffer argument is already shown on an iconified frame? >> Maybe we could make the *Completions* frame (optionally) invisible >> instead of iconfying it? > > What's "invisible" in this respect? (In any case, I'd try it out.) Hmm, invisible is invisible, see section 28.10 of the Elisp manual. That is, we could make the frame optionally invisible and make it visible again when it's needed. For example, when I evaluate the following three forms step by step (setq my-frame (make-frame)) (make-frame-invisible my-frame) (make-frame-visible my-frame) my-frame is visible and has input focus after the third step. If I do (let ((frame (selected-frame))) (make-frame-visible my-frame) (raise-frame frame)) as third step, the original frame is in the foreground, and if I do (let ((frame (selected-frame))) (make-frame-visible my-frame) (redirect-frame-focus my-frame frame)) as third step, my-frame is risen but typing input goes to the original frame. So there's a lot to experiment with for *Completions* and I'd invite people to try out what works for them and their window managers. martin ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Usage examples of dedicated windows and popup frames? 2011-07-10 15:30 ` martin rudalics @ 2011-07-10 16:00 ` Tassilo Horn 2011-07-10 21:13 ` Drew Adams 0 siblings, 1 reply; 26+ messages in thread From: Tassilo Horn @ 2011-07-10 16:00 UTC (permalink / raw) To: martin rudalics; +Cc: Stefan Monnier, emacs-devel martin rudalics <rudalics@gmx.at> writes: >> However, `other-frame' raises and selects correctly. > > Does `pop-to-buffer-other-frame' raise and select correctly when the > buffer argument is already shown on an iconified frame? Yes, it does. >>> Maybe we could make the *Completions* frame (optionally) invisible >>> instead of iconfying it? >> >> What's "invisible" in this respect? (In any case, I'd try it out.) > > Hmm, invisible is invisible, see section 28.10 of the Elisp manual. > That is, we could make the frame optionally invisible and make it > visible again when it's needed. For example, when I evaluate the > following three forms step by step > > (setq my-frame (make-frame)) > (make-frame-invisible my-frame) > (make-frame-visible my-frame) > > my-frame is visible and has input focus after the third step. Yes, that's nice. I think that's better as a default action for frames showing completion, because it's less distracting if iconification is animated, and it doesn't clutter the window manager switcher with temporary frames you usually don't want to switch to anyway. > If I do > > (let ((frame (selected-frame))) > (make-frame-visible my-frame) > (raise-frame frame)) > > as third step, the original frame is in the foreground, Yes, here, too. > and if I do > > (let ((frame (selected-frame))) > (make-frame-visible my-frame) > (redirect-frame-focus my-frame frame)) > > as third step, my-frame is risen but typing input goes to the original > frame. After evaluating that form, my emacs froze so that I had to kill it. C-g didn't work anymore. However, I cannot reproduce that with emacs -Q... Bye, Tassilo ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Usage examples of dedicated windows and popup frames? 2011-07-10 16:00 ` Tassilo Horn @ 2011-07-10 21:13 ` Drew Adams 0 siblings, 0 replies; 26+ messages in thread From: Drew Adams @ 2011-07-10 21:13 UTC (permalink / raw) To: 'Tassilo Horn', 'martin rudalics' Cc: 'Stefan Monnier', emacs-devel > >>> Maybe we could make the *Completions* frame (optionally) invisible > >>> instead of iconfying it? Whatever we decide to do, the behavior should be easily under user control. We can decide on a _default_ behavior (iconify, delete, make invisible, do nothing,...), but the user should be able to choose (easily). > >> What's "invisible" in this respect? (In any case, I'd try it out.) > > > > Hmm, invisible is invisible, see section 28.10 of the Elisp manual. > > That is, we could make the frame optionally invisible and make it > > visible again when it's needed. For example, when I evaluate the > > following three forms step by step > > (setq my-frame (make-frame)) > > (make-frame-invisible my-frame) > > (make-frame-visible my-frame) > > my-frame is visible and has input focus after the third step. > > Yes, that's nice. I think that's better as a default action > for frames showing completion, because it's less distracting if > iconification is animated, and it doesn't clutter the window > manager switcher with temporary frames you usually don't want to > switch to anyway. I have used invisible frames. But, FWIW, every time I wrote something about invisible frames here I heard back from "those who know" (TM) that invisible frames are broken, i.e., there are some problems with them (things that don't work). I never found out what those problematic things were or why they wouldn't/couldn't be fixed. Just mentioning this. Maybe there are some problems with invisible frames. > > If I do > > (let ((frame (selected-frame))) > > (make-frame-visible my-frame) > > (raise-frame frame)) > > as third step, the original frame is in the foreground, > > Yes, here, too. > > > and if I do > > (let ((frame (selected-frame))) > > (make-frame-visible my-frame) > > (redirect-frame-focus my-frame frame)) > > as third step, my-frame is risen but typing input goes to > > the original frame. > > After evaluating that form, my emacs froze so that I had to kill it. > C-g didn't work anymore. However, I cannot reproduce that with emacs > -Q... My take on the _default_ behavior (see above wrt user control) is that the frame should be deleted, not made invisible (and not iconified). I use frames a lot. Invisible frames constitute a useful set of frames for frame and frame-configuration operations. I do not want temporary frames such as those for user input dialogs to clutter up the list of invisible frames when they are "removed". That's not removal, it's simply non-display. An analogy that everyone is familiar with is having "invisible" (i.e., undisplayed) buffers around. You might not be very familiar with manipulating frames or sets of frames, including those that are invisible, but you sure are familiar with doing somewhat similar things with buffers. For buffers, we even went to the trouble of creating a special (syntactic) class of buffers that are ignored by many operations: those whose names start with a space char. That's a hack (OK, but rudimentary) to distinguish the unimportant "invisible" buffers from the other "invisible" buffers. Let's not go that way wrt invisible frames. AFAICT, there is no need to keep temporary, dialog frames around, in any state, once their raison d'etre (the dialog) is finished. Adding temporary user-input dialog pop-up frames (such as *Completions* or the list of marked files for a Dired operation) to the set of invisible frames is not the way to go, at least for anyone who actually uses invisible frames. That should at least not be the default behavior, IMO. Doing that would make using invisible frames even less useful than it is today (where there are supposedly a few problems). The default behavior should be to _delete_ the frame, IMO. A temporary, pop-up frame generally has no need to live on, even in some phantom state. Get it out of there altogether. If there is another dialog then a new frame will be popped up for it - nothing lost, no problem. ^ permalink raw reply [flat|nested] 26+ messages in thread
* RE: Usage examples of dedicated windows and popup frames? 2011-07-08 14:19 Usage examples of dedicated windows and popup frames? Tassilo Horn ` (2 preceding siblings ...) 2011-07-08 16:11 ` Stefan Monnier @ 2011-07-08 16:11 ` Drew Adams 3 siblings, 0 replies; 26+ messages in thread From: Drew Adams @ 2011-07-08 16:11 UTC (permalink / raw) To: 'Tassilo Horn', emacs-devel > Since lately I've read of many people on this list that they are using > dedicated windows, dedicated minibuffer frames, and popup frames... > [I would like some] help finding some appealing overall configuration > that just works for me. I'm happy to see interest in using frames more with Emacs! The more people try, the more they will encounter a few things, as you did, that don't quite work right. Bringing attention to such problems is a good thing. IMO, it's been too bad that Emacs Dev has long more or less neglected the non-nil `pop-up-frames' case. I'm not faulting anyone - that's probably to be expected, since most people use nil `pop-up-frames'. But it's a chicken-and-egg thing too: People who do try non-nil `pop-up-frames' generally give up, precisely because of the problems they encounter and the lack of obvious ways to work around them. Problems such as those you ran into. And Emacs Dev is also consequently at a disadvantage when someone who does use `pop-up-frames' reports a frames-related bug. Because I have workaround code to deal with such problems, when I report a bug involving some frame behavior I need to provide also my setup code (or a pared down version of it) to help developers reproduce the bug. This can mean a lot of extra work for both me and the developer investigating (e.g. Martin). > And basically it's not that bad. Good to hear. Out of the box, I think it's mostly there. But there are definitely a few wrinkles to be ironed out. > But after using it for an hour, I have more than 10 open emacs > frames now. Most of them were opened for showing completion > possibilities, but after I've finished completion they became > useless. It would be great if those would be > closed automagically... I use several frames at once, and that's not a problem in general for the frames I want to continue working with. I can easily work with a bunch of them at once. (Thumbifying is handy for this: http://www.emacswiki.org/emacs/FisheyeWithThumbs.) But what _is_ a problem are frames that get popped up for temporary purposes and then remain - as you mentioned wrt *Completions*. This is actually not that common aside from *Completions*, but it does happen occasionally. It would be great for Emacs to have a good, general solution. In my own use, I: 1. Use a dedicated frame for *Completions*. 2. Use a standalone minibuffer frame. 3. Redirect the *Completions* frame's keyboard input (focus) to the minibuffer frame. 4. Automatically delete the *Completions* frame when completion is finished. (The first three are provided by `oneonone.el', the last by Icicles.) I'm not suggesting that this should be the way to go for a general Emacs solution (dunno). I'm just mentioning that it is what I do - just one data point to consider. I've made it available and mentioned it to Emacs Dev for many years now. I've used it everyday in Emacs versions from 20 through 24, and it works for me. I think that Stefan also uses a standalone minibuffer frame and non-nil `pop-up-frames'. But I think he uses (weakly) dedicated windows pretty much everywhere. I generally use normal (not dedicated) windows. I use (fully) dedicated windows only for buffers with names `*...*'. Stefan presumably never changes the buffer shown in a given window; I do (e.g. `C-x f', `C-x C-v') - in normal windows. It would be interesting to see Stefan's solution to the problems/annoyances, i.e., to see his personal setup. But AFAIK he has never exposed his setup, let alone proposed its frame-oriented solutions for Emacs. Like you, Tassilo, I would like to see a workable-out-of-the-box solution for non-nil `pop-up-frames' (or whatever the Emacs 24 equivalent will finally turn out to be) - that is, for letting users use frames in a general way. I have my own solution, but I'm also interested in Emacs providing something out of the box. I've solved the *Completions* problem for myself, by following the logic of completion and getting rid of the *Completions* frame when it is no longer needed. Completion is in effect a dialog, and when that dialog is finished there is no longer any reason to show *Completions*. But now and again (rarely) I run into a similar problem wrt other "temporary" pop-up frames such as the list of flagged or marked files for Dired operations. I make `*...*' buffers be "special-display", so they get their own dedicated windows/frames, and their frames hang around after the "temporary" dialog is finished (e.g. the Dired operation). To me this is a (minor) hassle. Emacs should IMHO treat such a dialog as what it really is: a (non-modal) user _dialog_. Displaying a list of files and asking if you really want to delete them is fine, but that files display should then disappear (duh) after you've answered the question, regardless of whether it is in a separate frame, dedicated window, etc. Emacs Dev handles the pop-up window case OK here, but not the pop-up frame case - see, e.g., bug #7533. To me, this kind of thing should be a no-brainer (in terms of need to fix, not necessarily in terms of ease of implementation), but the "second-class citizenship" of frames in Emacs effectively relegates it to the dust bin. ;-) If more people become interested in making frames work then it's likely there will be more attention to fixing such problems. > Long story short: it would be nice if some people with non-standard > window/frame settings could share and briefly explain their > configuration. I'm very interested. Me too. The more the merrier. I'm very glad to see people take interest in the problem. No doubt this is due partly to Martin's recent changes to the display-buffer code. And no doubt those changes will affect how such problems should be handled going forward. No doubt I will need to update my own way of dealing with these problems, since `pop-up-frames' is being deprecated. If you are interested in my settings, which still work with Emacs 24 but which also still use `pop-up-frames' so far, you can see a description (and code) here: http://www.emacswiki.org/emacs/OneOnOneEmacs Add to that Icicles's auto-deletion of the *Completions* frame. At various points in the completion code I call a function that removes the *Completions* window. And in the case where that window is in its own dedicated frame, it deletes the frame (it's actually a bit more complicated, but that's the idea). That's about it. > And maybe it's a good idea to ship emacs with some predefined setups > users can easily try out and then extend to find one that suits them > best, for example, the current default window oriented configuration, a > more frame oriented configuration, and a frame oriented configuration > with a dedicated minibuffer frame, too. 1+ ! ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2011-07-13 23:09 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-07-08 14:19 Usage examples of dedicated windows and popup frames? Tassilo Horn 2011-07-08 14:47 ` Richard Riley 2011-07-08 14:49 ` John Yates 2011-07-08 16:11 ` Stefan Monnier 2011-07-08 16:34 ` Drew Adams 2011-07-08 16:51 ` Stefan Monnier 2011-07-08 17:38 ` Drew Adams 2011-07-08 17:54 ` Tassilo Horn 2011-07-08 18:55 ` Stefan Monnier 2011-07-09 13:00 ` martin rudalics 2011-07-09 15:03 ` Drew Adams 2011-07-10 0:43 ` chad 2011-07-10 9:00 ` martin rudalics 2011-07-10 9:43 ` Drew Adams 2011-07-12 17:47 ` chad 2011-07-12 18:55 ` Drew Adams 2011-07-13 6:24 ` martin rudalics 2011-07-13 23:09 ` chad 2011-07-10 23:45 ` undisplay temporary dialog buffers when done [was: ... dedicated windows and popup frames] Drew Adams 2011-07-09 17:22 ` Usage examples of dedicated windows and popup frames? Tassilo Horn 2011-07-10 9:00 ` martin rudalics 2011-07-10 9:39 ` Tassilo Horn 2011-07-10 15:30 ` martin rudalics 2011-07-10 16:00 ` Tassilo Horn 2011-07-10 21:13 ` Drew Adams 2011-07-08 16:11 ` Drew Adams
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).