Usage examples of dedicated windows and popup frames?

Usage examples of dedicated windows and popup frames?

[Tassilo Horn]

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

Re: Usage examples of dedicated windows and popup frames?

[Richard Riley]

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

Re: Usage examples of dedicated windows and popup frames?

[John Yates]

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

Re: Usage examples of dedicated windows and popup frames?

[Stefan Monnier]

>   (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

RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

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

Re: Usage examples of dedicated windows and popup frames?

[Stefan Monnier]

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

RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

> >> "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.

Re: Usage examples of dedicated windows and popup frames?

[Tassilo Horn]

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

Re: Usage examples of dedicated windows and popup frames?

[Stefan Monnier]

> 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

Re: Usage examples of dedicated windows and popup frames?

[martin rudalics]

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

RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

>  >> 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).

Re: Usage examples of dedicated windows and popup frames?

[chad]

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

Re: Usage examples of dedicated windows and popup frames?

[martin rudalics]

 > 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

RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

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

Re: Usage examples of dedicated windows and popup frames?

[chad]

[-- 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 --]

RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

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

Re: Usage examples of dedicated windows and popup frames?

[martin rudalics]

 > 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

Re: Usage examples of dedicated windows and popup frames?

[chad]

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

undisplay temporary dialog buffers when done [was: ... dedicated windows and popup frames]

[Drew Adams]

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))))

Re: Usage examples of dedicated windows and popup frames?

[Tassilo Horn]

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

Re: Usage examples of dedicated windows and popup frames?

[martin rudalics]

 > 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

Re: Usage examples of dedicated windows and popup frames?

[Tassilo Horn]

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

Re: Usage examples of dedicated windows and popup frames?

[martin rudalics]

 > 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

Re: Usage examples of dedicated windows and popup frames?

[Tassilo Horn]

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

RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

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

RE: Usage examples of dedicated windows and popup frames?

[Drew Adams]

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