managing windows in two frames

managing windows in two frames

[Stephen Leake]

I'd like to add the following functions to Emacs:

(defun display-buffer-reuse-frame (buffer alist)
  "Display BUFFER in an existing frame other than the current frame.
If successful, return the window used; otherwise return nil.

If ALIST has a non-nil `inhibit-switch-frame' entry, avoid
raising the frame.

If ALIST has a non-nil `pop-up-frame-parameters' entry, the
corresponding value is an alist of frame parameters to give the
new frame."
  (let* ((frame (car (filtered-frame-list
		      (lambda (frame)
			(and
			 (not (eq frame (selected-frame)))
			 (not (window-dedicated-p
			       (or
				(get-lru-window frame)
				(frame-first-window frame)))))))))
	 (window
	  (and frame
	       (or
		(get-lru-window frame)
		;; lru-window can be nil if window was deleted, by ediff for example
		(frame-first-window frame-2))))
	 )
    (when window
      (prog1 (window--display-buffer
	      buffer window 'frame alist display-buffer-mark-dedicated)
	(unless (cdr (assq 'inhibit-switch-frame alist))
	  (window--maybe-raise-frame frame))))
    ))

(defun display-buffer-other-window-or-frame (buffer alist)
  "Depending on `current-prefix-arg', show BUFFER in another window or frame.
If current-prefix-arg is:
'(4) - from C-u; show buffer in another window in current frame, creating new if needed.
'(16) - from C-u C-u; show buffer in another frame, creating new if needed.
other - return nil."
  (or
   (cond
    ((equal current-prefix-arg '(4)) ;; other window
     (or (display-buffer-use-some-window buffer '((inhibit-same-window . t)))
	 (display-buffer-pop-up-window buffer nil)))

    ((equal current-prefix-arg '(16)) ;; other frame
     (or (display-buffer-reuse-frame buffer '((reusable-frames . visible)))   ;; reuse a window in other frame
	 (display-buffer-pop-up-frame buffer nil)))

    (t nil)

    )))

(defun sal-move-to-other-frame ()
  "Move current buffer to a window in another frame."
  (interactive)
  (let ((buffer (current-buffer)))
    (switch-to-prev-buffer nil 'bury)
    (let ((display-buffer-overriding-action
	   '((display-buffer-reuse-frame buffer display-buffer-pop-up-frame)
	     . '((reusable-frames . visible)))))   ;; reuse a window in other frame
      (display-buffer buffer))))


The use case for these:

I use two Emacs frames, side by side, filling the screen. This allows
two things:

1) opening other applications next to an Emacs frame

2) navigating between frames for horizontal movement (using window
manager keys), and between windows for vertical movement (using Emacs
keys).

With one Emacs frame, split both horizontally and vertically, I find it
difficult to navigate among the windows.

`display-buffer-reuse-frame' allows displaying a buffer in the other
frame, without always creating a new frame.

`display-buffer-other-window-or-frame' gives the user flexible control
of all buffer display functions, via the prefix arg.

`sal-move-to-other-frame' is convenient for rearranging the buffers in
the display. (needs another name for inclusion in Emacs).

In my ~/.emacs, I set:

(setq display-buffer-base-action
      '((display-buffer-reuse-window
	 display-buffer-other-window-or-frame)
	.
	((reusable-frames . visible))))

Thoughts?

-- 
-- Stephe

Re: managing windows in two frames

[martin rudalics]

 > (defun display-buffer-reuse-frame (buffer alist)

I'd call it `display-buffer-other-frame' ("reuse" currently has the
connotation that a window already displays the buffer in question).

 >   "Display BUFFER in an existing frame other than the current frame.
 > If successful, return the window used; otherwise return nil.
 >
 > If ALIST has a non-nil `inhibit-switch-frame' entry, avoid
 > raising the frame.
 >
 > If ALIST has a non-nil `pop-up-frame-parameters' entry, the
 > corresponding value is an alist of frame parameters to give the
 > new frame."
 >   (let* ((frame (car (filtered-frame-list

This is overly restrictive.  We should be able to choose any window on
any frame.  If necessary, we can invent a new alist element for picking
a frame.

 > 		      (lambda (frame)
 > 			(and
 > 			 (not (eq frame (selected-frame)))
 > 			 (not (window-dedicated-p
 > 			       (or
 > 				(get-lru-window frame)
 > 				(frame-first-window frame)))))))))

The lru and first window of that frame could denote the same window.
Here too we can add a new alist element for picking the window.

 > 	 (window
 > 	  (and frame
 > 	       (or
 > 		(get-lru-window frame)
 > 		;; lru-window can be nil if window was deleted, by ediff for example

Can you give a scenario?  `get-lru-window' doesn't consider/return
deleted windows IIRC.  It can return nil if all windows are dedicated or
slelected.

 > 		(frame-first-window frame-2))))

What is frame-2 ?

 > 	 )
 >     (when window
 >       (prog1 (window--display-buffer
 > 	      buffer window 'frame alist display-buffer-mark-dedicated)
 > 	(unless (cdr (assq 'inhibit-switch-frame alist))
 > 	  (window--maybe-raise-frame frame))))
 >     ))
 >
 > (defun display-buffer-other-window-or-frame (buffer alist)
 >   "Depending on `current-prefix-arg', show BUFFER in another window or frame.
 > If current-prefix-arg is:
 > '(4) - from C-u; show buffer in another window in current frame, creating new if needed.
 > '(16) - from C-u C-u; show buffer in another frame, creating new if needed.
 > other - return nil."

`display-buffer' decisions are currently not based on a prefix argument
given.  Maybe we can reconcile your idea with Stefan's proposal to use
special prefixes for `display-buffer'-based functions.

 >   (or
 >    (cond
 >     ((equal current-prefix-arg '(4)) ;; other window
 >      (or (display-buffer-use-some-window buffer '((inhibit-same-window . t)))
 > 	 (display-buffer-pop-up-window buffer nil)))
 >
 >     ((equal current-prefix-arg '(16)) ;; other frame
 >      (or (display-buffer-reuse-frame buffer '((reusable-frames . visible)))   ;; reuse a window in other frame
 > 	 (display-buffer-pop-up-frame buffer nil)))
 >
 >     (t nil)
 >
 >     )))
 >
 > (defun sal-move-to-other-frame ()
 >   "Move current buffer to a window in another frame."
 >   (interactive)
 >   (let ((buffer (current-buffer)))
 >     (switch-to-prev-buffer nil 'bury)
 >     (let ((display-buffer-overriding-action
 > 	   '((display-buffer-reuse-frame buffer display-buffer-pop-up-frame)
 > 	     . '((reusable-frames . visible)))))   ;; reuse a window in other frame
 >       (display-buffer buffer))))
 >
 >
 > The use case for these:
 >
 > I use two Emacs frames, side by side, filling the screen. This allows
 > two things:
 >
 > 1) opening other applications next to an Emacs frame

If Emacs fills the screen there doesn't seem much space left for other
applications ;-)

 > 2) navigating between frames for horizontal movement (using window
 > manager keys), and between windows for vertical movement (using Emacs
 > keys).
 >
 > With one Emacs frame, split both horizontally and vertically, I find it
 > difficult to navigate among the windows.

I'm using M-S-left, M-S-up ... to navigate to the window in that
direction.

 > `display-buffer-reuse-frame' allows displaying a buffer in the other
 > frame, without always creating a new frame.

Such functionality is missing, indeed.

 > `display-buffer-other-window-or-frame' gives the user flexible control
 > of all buffer display functions, via the prefix arg.

We have to decide how to integrate pefix arguments in buffer display
functions.  So far, I don't know of a proposal that allows, for example,
to use the "same" window, thus overriding an application that wants to
display the buffer in another window.

martin

Re: managing windows in two frames

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>> (defun display-buffer-reuse-frame (buffer alist)
>
> I'd call it `display-buffer-other-frame' ("reuse" currently has the
> connotation that a window already displays the buffer in question).

Ah; I was focused on "don't create a frame", similar to
`display-buffer-reuse-window' doesn't create a window. But you are
correct about it implying the buffer is already shown in that frame.

>>   "Display BUFFER in an existing frame other than the current frame.
>> If successful, return the window used; otherwise return nil.
>>
>> If ALIST has a non-nil `inhibit-switch-frame' entry, avoid
>> raising the frame.
>>
>> If ALIST has a non-nil `pop-up-frame-parameters' entry, the
>> corresponding value is an alist of frame parameters to give the
>> new frame."
>>   (let* ((frame (car (filtered-frame-list
>
> This is overly restrictive.  

I'm not clear what you would relax. We don't want the current frame, and
we want a frame with an available window.

I guess we could allow creating a new window in an existing frame? So
far I have not encountered a case where that is needed.

>> 		      (lambda (frame)
>> 			(and
>> 			 (not (eq frame (selected-frame)))
>> 			 (not (window-dedicated-p
>> 			       (or
>> 				(get-lru-window frame)
>> 				(frame-first-window frame)))))))))
>
> The lru and first window of that frame could denote the same window.

Yes, in which case we might miss an available window.

> Here too we can add a new alist element for picking the window.

Yes, I did not try to add new 'get a window from a frame' functions, but
that could be useful here.

In practice, this has not yet done the wrong thing for me.

>> 	 (window
>> 	  (and frame
>> 	       (or
>> 		(get-lru-window frame)
>> 		;; lru-window can be nil if window was deleted, by ediff for example
>
> Can you give a scenario?  `get-lru-window' doesn't consider/return
> deleted windows IIRC.  It can return nil if all windows are dedicated or
> slelected.

When I started on this, it would fail after I ran and quit ediff, so I
blamed it on deleted windows. But I have not tried to reproduce that
problem in Emacs 24.3.

>> 		(frame-first-window frame-2))))
>
> What is frame-2 ?

Hmm. A bug; it should be 'frame'. It's left over from an earlier version
of the code. Since I didn't notice the bug, this demonstrates that
get-lru-window doesn't return nil currently.

> `display-buffer' decisions are currently not based on a prefix argument
> given.  

Right; that's new. I find it very convenient.

> Maybe we can reconcile your idea with Stefan's proposal to use
> special prefixes for `display-buffer'-based functions.

Searching the emacs-devel archives, I found:

http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00299.html

http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00481.html

That doesn't give a very concrete proposal; can provide a better link?

If it is as simple as C-u C-u, it would work for me.

So far, I have not found a conflict between using C-u for window/frame
choice and other uses, but there probably are some.

In general, having only one prefix command (really two, since C-u C-u is
different from C-u, as is C-u C-u C-u for that matter) is restrictive.

>> The use case for these:
>>
>> I use two Emacs frames, side by side, filling the screen. This allows
>> two things:
>>
>> 1) opening other applications next to an Emacs frame
>
> If Emacs fills the screen there doesn't seem much space left for other
> applications ;-)

That is the point of the two frames; when I need to see another
application, I still want half a screen of Emacs. If Emacs was one
frame, it would hide the other application when I switch back to it, or
I'd have to resize the frame, which would squeeze all the windows.

Half a screen is better than squeezed windows.

>> 2) navigating between frames for horizontal movement (using window
>> manager keys), and between windows for vertical movement (using Emacs
>> keys).
>
> I'm using M-S-left, M-S-up ... to navigate to the window in that
> direction.

Bound to windmove-*, I assume. Someone else pointed those out privately;
I had not been aware of them. That does solve this part of my use case.

Although I've already bound all the M-S-C-<arrow> keys; it would be a
big change to switch to that now :).

>> `display-buffer-other-window-or-frame' gives the user flexible control
>> of all buffer display functions, via the prefix arg.
>
> We have to decide how to integrate pefix arguments in buffer display
> functions.  

Yes.

> So far, I don't know of a proposal that allows, for example,
> to use the "same" window, thus overriding an application that wants to
> display the buffer in another window.

Good point; I have not considered trying to implement that. There are
times when it is annoying to have a command use another window.
Especially now that I'm used to using my prefix commands for most
window/frame management. 

In the long run, I would hope that the user interface for choosing
another window/frame is easy enough to use that no application would
decide to use another window or frame, always leaving it up to the user.

-- 
-- Stephe

Re: managing windows in two frames

[Stephen Leake]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> martin rudalics <rudalics@gmx.at> writes:
>
>>> (defun display-buffer-reuse-frame (buffer alist)
>>
>> I'd call it `display-buffer-other-frame' ("reuse" currently has the
>> connotation that a window already displays the buffer in question).
>
> Ah; I was focused on "don't create a frame", similar to
> `display-buffer-reuse-window' doesn't create a window. But you are
> correct about it implying the buffer is already shown in that frame.

However, `display-buffer-other-frame' is already defined in window.el;
it's a user-level function, so I don't think we can use that name. 

`display-buffer-existing-frame' would work.

It would make sense to add `display-buffer-reuse-frame' to
display-buffer--other-frame-action, at least for my style.

-- 
-- Stephe

Re: managing windows in two frames

[Stefan Monnier]

>> `display-buffer' decisions are currently not based on a prefix argument
>> given.
> Right; that's new. I find it very convenient.

But it's fundamentally broken (the prefix arg is an argument to the
command being run, and the relationship between the command being run
and the call to `display-buffer' can be arbitrary).
IOW it's perfectly fine for personal use but we can't use that in
lisp/window.el.

>> Maybe we can reconcile your idea with Stefan's proposal to use
>> special prefixes for `display-buffer'-based functions.
> Searching the emacs-devel archives, I found:
> http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00299.html
> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00481.html
> That doesn't give a very concrete proposal; can provide a better link?

Make C-x 5 a prefix key which sets display-buffer-overriding-action for
the duration of the next command.

So C-x 5 C-x C-f will do the same as what you currently get with C-x 5 f
(of course, we'd also preserve a C-x 5 f binding for backward
compatibility, and we wouldn't need find-file-other-frame any more,
although we'd also have to keep it for backward compatibility).

Of course, other such prefixes could be used, such as C-x 4.  And as
Martin mentions, we'd want one that can say "display in current
window".  That should be no harder to define than C-x 4 or C-x 5.

More generally you could define such a prefix key that lets you specify
a particular window to use in the next command.


        Stefan

Re: managing windows in two frames

[Stephen Leake]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> `display-buffer' decisions are currently not based on a prefix argument
>>> given.
>> Right; that's new. I find it very convenient.
>
> But it's fundamentally broken (the prefix arg is an argument to the
> command being run, and the relationship between the command being run
> and the call to `display-buffer' can be arbitrary).
> IOW it's perfectly fine for personal use but we can't use that in
> lisp/window.el.

Yes, that makes sense.

>>> Maybe we can reconcile your idea with Stefan's proposal to use
>>> special prefixes for `display-buffer'-based functions.
>> Searching the emacs-devel archives, I found:
>> http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00299.html
>> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00481.html
>> That doesn't give a very concrete proposal; can provide a better link?
>
> Make C-x 5 a prefix key which sets display-buffer-overriding-action for
> the duration of the next command.

Ok; that makes sense as a user interface.

Do you have a hint about how to implement it? I've never seen code tied
to a prefix, but I'm happy to experiment.

> Of course, other such prefixes could be used, such as C-x 4.  

Right, that would be "other window" (C-x 4 f is
`find-file-other-window'), while C-x 5 is "other frame". 

> And as Martin mentions, we'd want one that can say "display in current
> window". That should be no harder to define than C-x 4 or C-x 5.

C-x 6 is available. But display-buffer is not used for displaying a
buffer in the current window now, so I think this cannot be handled by
the same mechanism. At least not without major changes.

> More generally you could define such a prefix key that lets you specify
> a particular window to use in the next command.

Right. Designing a UI to let users select a particular window is a
challenge. I may think about that later ...

-- 
-- Stephe

Re: managing windows in two frames

[martin rudalics]

 > C-x 6 is available. But display-buffer is not used for displaying a
 > buffer in the current window now, so I think this cannot be handled by
 > the same mechanism. At least not without major changes.

`display-buffer-same-window'?  Or what am I missing?

martin

Re: managing windows in two frames

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>> C-x 6 is available. But display-buffer is not used for displaying a
>> buffer in the current window now, so I think this cannot be handled by
>> the same mechanism. At least not without major changes.
>
> `display-buffer-same-window'?  Or what am I missing?

`find-file' does not call `display-buffer'; `find-file-other-window'
does call `display-buffer'. (I just checked by enabling Edebug in
display-buffer.)

`find-file' calls `switch-to-buffer' which calls `pop-to-buffer'.

The same is true for all the other "put a buffer in this window"
user level functions I've encountered.

`display-buffer-same-window' is an action for `display-buffer'.

Ah! We could change the implementation of `find-file' to use
`display-buffer' with an action of `display-buffer-same-window'; that
action would be changed by prefix C-x 4 or C-x 5.

`find-file-other-window' could then be implemented by setting
`display-buffer-overriding-action' and calling `find-file'.
 
That would make sense, and should be mostly transparent to users. All
the other similar functions would have to be changed in a similar way -
I haven't tried to enumerate them. We could implement C-x 4 and 5 for
the current uses of `display-buffer' first, and see how people like it.

-- 
-- Stephe

Re: managing windows in two frames

[martin rudalics]

 > `find-file' does not call `display-buffer'; `find-file-other-window'
 > does call `display-buffer'. (I just checked by enabling Edebug in
 > display-buffer.)
 >
 > `find-file' calls `switch-to-buffer' which calls `pop-to-buffer'.

Usually, `switch-to-buffer' simply sets the buffer of the selected
window.  It calls `pop-to-buffer' only if something unexpected happens.
But you're right in the sense that `find-file' is usually not affected
by `display-buffer-alist'.

 > The same is true for all the other "put a buffer in this window"
 > user level functions I've encountered.

Right.  There was a period where Stefan wanted to deprecate calls of
`switch-to-buffer' from Elisp but later Chong restored the old behavior
(and neither wanted to change the specification of `switch-to-buffer'
itself).  IIRC he simply wanted to keep the old semantics unchanged.

 > `display-buffer-same-window' is an action for `display-buffer'.
 >
 > Ah! We could change the implementation of `find-file' to use
 > `display-buffer' with an action of `display-buffer-same-window'; that
 > action would be changed by prefix C-x 4 or C-x 5.

Yes.  We'd definitely have to replace all `switch-to-buffer' calls to
propose an action like `display-buffer-same-window' if we wanted to make
the prefixes work here.  But we have to do it in some "overriding" sense
to make sure that a user's "general" `display-buffer-alist' settings
don't interfere with the semantics of the current operation.

 > `find-file-other-window' could then be implemented by setting
 > `display-buffer-overriding-action' and calling `find-file'.
 >
 > That would make sense, and should be mostly transparent to users. All
 > the other similar functions would have to be changed in a similar way -
 > I haven't tried to enumerate them. We could implement C-x 4 and 5 for
 > the current uses of `display-buffer' first, and see how people like it.

We first have to handle the case where `display-buffer' pops up a
*Completions* window (which might pop up a *Backtrace* window ...).  I
yet have no good idea how to do that.

martin

Re: managing windows in two frames

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

> We first have to handle the case where `display-buffer' pops up a
> *Completions* window (which might pop up a *Backtrace* window ...).  I
> yet have no good idea how to do that.

If those buffers pop up in the same place that the user's requested
buffer does, so they are replaced by the user buffer, that's consistent
with what the user requested.

So the display-buffer settings for the user's requested buffer should
apply to any intermediate buffers as well.

But I don't remember encountering that use case, so maybe I'm wrong.

-- 
-- Stephe

Re: managing windows in two frames

[martin rudalics]

 > If those buffers pop up in the same place that the user's requested
 > buffer does, so they are replaced by the user buffer, that's consistent
 > with what the user requested.
 >
 > So the display-buffer settings for the user's requested buffer should
 > apply to any intermediate buffers as well.

This might violate the principle of least surprise.  Suppose I'm used to
pop up the *Completions* buffer right above the minibuffer window and a
command to display some file on another frame gets me the *Completions*
buffer on a new frame.  In particular, we cannot claim that C-x 5 f does
the same it did before.

martin

RE: managing windows in two frames

[Drew Adams]

> Make C-x 5 a prefix key which sets display-buffer-overriding-action for
> the duration of the next command.
> 
> So C-x 5 C-x C-f will do the same as what you currently get with C-x 5 f
> (of course, we'd also preserve a C-x 5 f binding for backward
> compatibility, 

For more than just that, no?  `C-x 5 C-x C-f' is not as simple as
`C-x 5 f'.  Occam would grumble.

Yes, Occam might be somewhat happy to eliminate the "extra" commands
`*-other-window' and `*-other-frame', and just have `*'.  But the devil
is in the details.  It's not clear, so far, whether users would find
this simpler or more complicated.

> and we wouldn't need find-file-other-frame any more,

Do you mean only for `C-x 5 f'?  Someone will likely want to bind such
a command (or whatever it becomes) to additional keys, no?  Sure s?he
could make do with a lambda expression or whatever, if necessary.
But why?  (It's not clear to me just what you have in mind.)

> although we'd also have to keep it for backward compatibility).

For more than just that, I expect...

> Of course, other such prefixes could be used, such as C-x 4.

BTW, what do you do with `C-x 4 C-x 5 C-x C-f'?  By your description,
I guess that does the same thing as `C-x 4 f'?

> And as Martin mentions, we'd want one that can say "display in current
> window".  That should be no harder to define than C-x 4 or C-x 5.

Suppose it were `C-x 6', for kicks.  Would `C-x 6 C-x 4 C-x 5 C-x C-f'
then be the same as `C-x C-f'?

Will you at least be keeping `C-x C-f' "for backward compatibility"?

> More generally you could define such a prefix key that lets you specify
> a particular window to use in the next command.

Could we see a spec of some kind (better description), before the
implementation and possible deprecations?

Re: managing windows in two frames

[martin rudalics]

 > Make C-x 5 a prefix key which sets display-buffer-overriding-action for
 > the duration of the next command.

This won't work well in one particular case (Michael Heerdegen recently
mentioned it on Emacs-help and I try to recall what he wrote): Suppose
when switching to a file interactively via `find-file' you set
`display-buffer-overriding-action' to some value for displaying the
file.  Now that command might pop up a window for completing the
filename calling `display-buffer' in a nested fashion.  Should that call
adhere to `display-buffer-overriding-action` or, as probably expected,
use the built-in or user-defined behavior for the *Completions* buffer?

martin

Re: managing windows in two frames

[Stefan Monnier]

>> Make C-x 5 a prefix key which sets display-buffer-overriding-action for
>> the duration of the next command.
> This won't work well in one particular case (Michael Heerdegen recently
> mentioned it on Emacs-help and I try to recall what he wrote): Suppose
> when switching to a file interactively via `find-file' you set
> `display-buffer-overriding-action' to some value for displaying the
> file.  Now that command might pop up a window for completing the
> filename calling `display-buffer' in a nested fashion.  Should that call
> adhere to `display-buffer-overriding-action` or, as probably expected,
> use the built-in or user-defined behavior for the *Completions* buffer?

Indeed, minibuffers and other forms of recursive edits need to be
adjusted (like they are for C-u).


        Stefan

Re: managing windows in two frames

[martin rudalics]

 >>>   (let* ((frame (car (filtered-frame-list
 >> This is overly restrictive.
 >
 > I'm not clear what you would relax. We don't want the current frame, and
 > we want a frame with an available window.
 >
 > I guess we could allow creating a new window in an existing frame?

No.  But consider the case where a user wants to have one and the same
frame share just *Help* and *info* output and that frame is the car of
filtered-frame-list.  Your approach is two-frames-centric - people might
use three frames or more.

 > When I started on this, it would fail after I ran and quit ediff, so I
 > blamed it on deleted windows. But I have not tried to reproduce that
 > problem in Emacs 24.3.

This problem should not occur in older versions either.

martin

Re: managing windows in two frames

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>>>>   (let* ((frame (car (filtered-frame-list
>>> This is overly restrictive.
>>
>> I'm not clear what you would relax. We don't want the current frame, and
>> we want a frame with an available window.
>>
>> I guess we could allow creating a new window in an existing frame?
>
> No.  But consider the case where a user wants to have one and the same
> frame share just *Help* and *info* output and that frame is the car of
> filtered-frame-list.  

So other windows would then be added to it sometimes, which is not what
the user wants. 

A general solution to that sort of problem would require a
user-specified filter for picking a frame; it could check if the frame
has *Help* and return nil.

>Your approach is two-frames-centric - people might
> use three frames or more.

Yes, more frames requires more a intelligent filter, or a more
interactive choice of frame (ie prompting with a list). 

But you said my current code is "overly restrictive"; here you are
proposing adding (user-specified) restrictions, not relaxing them.

-- 
-- Stephe

Re: managing windows in two frames

[martin rudalics]

 >> No.  But consider the case where a user wants to have one and the same
 >> frame share just *Help* and *info* output and that frame is the car of
 >> filtered-frame-list.
 >
 > So other windows would then be added to it sometimes, which is not what
 > the user wants.
 >
 > A general solution to that sort of problem would require a
 > user-specified filter for picking a frame; it could check if the frame
 > has *Help* and return nil.

Usually, this is done by making the *Help* frame dedicated.  But
dedicated windows are not very popular.

 >> Your approach is two-frames-centric - people might
 >> use three frames or more.
 >
 > Yes, more frames requires more a intelligent filter, or a more
 > interactive choice of frame (ie prompting with a list).
 >
 > But you said my current code is "overly restrictive"; here you are
 > proposing adding (user-specified) restrictions, not relaxing them.

I meant it's restrictive by paying attention only to the first frame of
what `filtered-frame-list' returns.

martin

Re: managing windows in two frames

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>>> Your approach is two-frames-centric - people might
>>> use three frames or more.
>>
>> Yes, more frames requires more a intelligent filter, or a more
>> interactive choice of frame (ie prompting with a list).
>>
>> But you said my current code is "overly restrictive"; here you are
>> proposing adding (user-specified) restrictions, not relaxing them.
>
> I meant it's restrictive by paying attention only to the first frame of
> what `filtered-frame-list' returns.

Yes. If it returns more, prompting the user with a list of frames to
choose from would be reasonable.

Which immediately runs into the issue of what frame & window to use for
the buffer containing that list. 

Since the user has not yet indicated the final frame, one choice is
using the first frame returned by `filtered-frame-list' for the prompt
buffer, as long as that frame is returned to its original state when the
prompt is completed. That could be done by an additional `dont-prompt'
parameter to the display-buffer action.

Another choice is the minibuffer, using completing-read. But that's not
very friendly, since it's hard to see the entire list of available
frames.

-- 
-- Stephe

Re: managing windows in two frames

[Stefan Monnier]

> If ALIST has a non-nil `inhibit-switch-frame' entry, avoid
> raising the frame.

That sounds wrong: inhibit-switch-frame means to not use another frame,
so the only correct behavior for your function is that when
inhibit-switch-frame is non-nil your function should return nil
right away.

You'd need another parameter to specify the "don't raise" behavior.

> (defun sal-move-to-other-frame ()
>   "Move current buffer to a window in another frame."
>   (interactive)
>   (let ((buffer (current-buffer)))
>     (switch-to-prev-buffer nil 'bury)
>     (let ((display-buffer-overriding-action
> 	   '((display-buffer-reuse-frame buffer display-buffer-pop-up-frame)
> 	     . '((reusable-frames . visible)))))   ;; reuse a window in other frame
>       (display-buffer buffer))))

Don't let-bind display-buffer-overriding-action here.
Just pass the relevant args to display-buffer.
display-buffer-overriding-action is only for use when you don't have
direct control over the call(s) to display-buffer.


        Stefan

Re: managing windows in two frames

[martin rudalics]

 > That sounds wrong: inhibit-switch-frame means to not use another frame,

`inhibit-switch-frame' non-nil means to not raise (and implicitly
select) another frame.

martin

Re: managing windows in two frames

[Stefan Monnier]

>> That sounds wrong: inhibit-switch-frame means to not use another frame,
> `inhibit-switch-frame' non-nil means to not raise (and implicitly
> select) another frame.

Hmm... I misunderstood (and misused) it, then.  How do I tell
display-buffer to not use another frame (I typically do that when
I want to make sure save-window-excursion will properly undo the
damage)?


        Stefan

Re: managing windows in two frames

[martin rudalics]

 > Hmm... I misunderstood (and misused) it, then.  How do I tell
 > display-buffer to not use another frame (I typically do that when
 > I want to make sure save-window-excursion will properly undo the
 > damage)?

Add another entry, say `inhibit-other-frame'?

But you should know better that using `save-window-excursion' around a
`display-buffer' call is bad karma.  A user can always request another
frame.

martin

Re: managing windows in two frames

[Stefan Monnier]

>> Hmm... I misunderstood (and misused) it, then.  How do I tell
>> display-buffer to not use another frame (I typically do that when
>> I want to make sure save-window-excursion will properly undo the
>> damage)?
> Add another entry, say `inhibit-other-frame'?

I meant: what is there currently available.

> But you should know better that using `save-window-excursion' around a
> `display-buffer' call is bad karma.  A user can always request another
> frame.

I do know it's terribly bad karma, but when all you have is a function
that "fills a buffer and displays it" and you only want the buffer,
without displaying it...


        Stefan

Re: managing windows in two frames

[martin rudalics]

 >> Add another entry, say `inhibit-other-frame'?
 >
 > I meant: what is there currently available.

  '((display-buffer-reuse-window
     display-buffer-pop-up-window
     display-buffer-use-some-window)
    (reusable-frames)))

 > ... when all you have is a function
 > that "fills a buffer and displays it" and you only want the buffer,
 > without displaying it...

Try `quit-restore-window'.

martin

Re: managing windows in two frames

[Stefan Monnier]

>>> Add another entry, say `inhibit-other-frame'?
>> I meant: what is there currently available.
>  '((display-buffer-reuse-window
>     display-buffer-pop-up-window
>     display-buffer-use-some-window)
>    (reusable-frames)))

Thanks.  Hmm... that's fairly convoluted.

>> ... when all you have is a function
>> that "fills a buffer and displays it" and you only want the buffer,
>> without displaying it...
> Try `quit-restore-window'.

Once a new frame has been created, it's too late.


        Stefan

Re: managing windows in two frames

[martin rudalics]

 > Once a new frame has been created, it's too late.

Why can't you delete it?

martin

Re: managing windows in two frames

[Stefan Monnier]

>> Once a new frame has been created, it's too late.
> Why can't you delete it?

You can, but that doesn't undo the fact that the user has seen it (and
may have had to place it manually on his desktop).


        Stefan

Re: managing windows in two frames

[martin rudalics]

 > You can, but that doesn't undo the fact that the user has seen it (and
 > may have had to place it manually on his desktop).

That's the user's problem since in this case she did override your
suggestion on not using another frame.  But you'd have to tell me more
details of why you want to use a function that displays a buffer you
don't want to display.  Is it because you want to test filling in a
hypothetical environment and postpone the decision on where to display
the buffer?

martin

Re: managing windows in two frames

[Stefan Monnier]

>> You can, but that doesn't undo the fact that the user has seen it (and
>> may have had to place it manually on his desktop).
> That's the user's problem since in this case she did override your
> suggestion on not using another frame.

The user's choice has nothing to do with it: let's say Jorge (someone
writing an Elisp package) wants to get the *Help* buffer that shows the
doc of a function, but he doesn't want to display it (e.g. because he
wants to process that buffer's content in some other way).

The only function he does have is one that displays the buffer
(additionally to filling the buffer with the data I want).
So he wants to trick that function into not displaying the buffer.

Typically, people use save-window-excursion for that, but it fails if
the buffer ends up displayed in some other frame (or worse, in a new
frame), which can happen depending on the user's settings.  So Jorge
really wants he code to work regardless of any user's customization of
display-buffer, in the same sense that find-file-noselect does not pay
attention to the user's display-buffer settings.


        Stefan

Re: managing windows in two frames

[martin rudalics]

 > The user's choice has nothing to do with it: let's say Jorge (someone
 > writing an Elisp package) wants to get the *Help* buffer that shows the
 > doc of a function, but he doesn't want to display it (e.g. because he
 > wants to process that buffer's content in some other way).
 >
 > The only function he does have is one that displays the buffer
 > (additionally to filling the buffer with the data I want).
 > So he wants to trick that function into not displaying the buffer.
 >
 > Typically, people use save-window-excursion for that,

That's irrational.  What's wrong with

(let ((display-buffer-function 'ignore))
   (describe-function 'ignore))

 > but it fails if
 > the buffer ends up displayed in some other frame (or worse, in a new
 > frame), which can happen depending on the user's settings.  So Jorge
 > really wants he code to work regardless of any user's customization of
 > display-buffer, in the same sense that find-file-noselect does not pay
 > attention to the user's display-buffer settings.

If he "sits close enough" to `display-buffer', Jorge can always (1) use
`display-buffer-function', (2) `display-buffer-overriding-action', or
(3) bind `display-buffer-alist' to do whatever he wants.

martin

Re: managing windows in two frames

[Stefan Monnier]

> That's irrational.

Not at all.  It's a half-common need (tho most people don't realize
that other frames could be involved so they just use
save-window-excursion thinking it'll undo any damage).

> What's wrong with
> (let ((display-buffer-function 'ignore))
>   (describe-function 'ignore))

Ah, indeed it's simpler.  It does have the disadvantage of relying on an
obsolete variable, tho.

>> but it fails if the buffer ends up displayed in some other frame (or
>> worse, in a new frame), which can happen depending on the user's
>> settings.  So Jorge really wants he code to work regardless of any
>> user's customization of display-buffer, in the same sense that
>> find-file-noselect does not pay attention to the user's
>> display-buffer settings.
> If he "sits close enough" to `display-buffer', Jorge can always (1) use
> `display-buffer-function', (2) `display-buffer-overriding-action', or
> (3) bind `display-buffer-alist' to do whatever he wants.

Of course a real fix is to change the code so that it provide
a "non-displaying" variant, but Jorge often doesn't have the necessary
control over that code.  In the case of lisp--company-doc-buffer (in
lisp.el), Jorge actually does have this control but doesn't have the
energy to "do it right".

(1) uses an obsolete var.
(3) binds a user variable, which is bad karma.
(2) is good, but the question remains: "bind it to what?".  You did
provide a answer to that question, admittedly, but it's a bit
longwinded, I think we should have a simpler answer.

Maybe we should define a new macro `with-inhibit-window-changes' which
could replace save-window-excursion for those uses (it might use
save-window-excursion internally, just in case, but would also try to
prevent creation of frames and window changes in other frames).


        Stefan

Re: managing windows in two frames

[martin rudalics]

 > Ah, indeed it's simpler.  It does have the disadvantage of relying on an
 > obsolete variable, tho.

I thought Jorge wanted something that works with existing (and elder)
Emacsen.

 > Maybe we should define a new macro `with-inhibit-window-changes' which
 > could replace save-window-excursion for those uses (it might use
 > save-window-excursion internally, just in case, but would also try to
 > prevent creation of frames and window changes in other frames).

We could easily do that but for one issue: Some buffer display calls
expect that neither snow nor rain will prevent Emacs from producing a
suitable window (compare bug#15213).

Also, a user's expectation that code following

   (pop-to-buffer (generate-new-buffer " *temp*"))

operates on the new buffer is not entirely silly given our current
understanding of `pop-to-buffer'.  Many years ago I asked here whether
anything might prevent the display of a buffer but no-one had the
courage to answer ...

martin

Re: managing windows in two frames

[Stefan Monnier]

>> Ah, indeed it's simpler.  It does have the disadvantage of relying on an
>> obsolete variable, tho.
> I thought Jorge wanted something that works with existing (and elder)
> Emacsen.

Both needs exist: to work in older Emacsen, and to be "clean and
simple".  I care more about the second one.

>> Maybe we should define a new macro `with-inhibit-window-changes' which
>> could replace save-window-excursion for those uses (it might use
>> save-window-excursion internally, just in case, but would also try to
>> prevent creation of frames and window changes in other frames).
> We could easily do that but for one issue: Some buffer display calls
> expect that neither snow nor rain will prevent Emacs from producing a
> suitable window (compare bug#15213).

I know, which is why with-inhibit-window-changes would probably not
really prevent changing windows; instead it would work hard to limit
window changes to those that can be fully reverted by
save-window-excursion.

> Also, a user's expectation that code following
>   (pop-to-buffer (generate-new-buffer " *temp*"))
> operates on the new buffer is not entirely silly given our current
> understanding of `pop-to-buffer'.

Indeed.  After pop-to-buffer it should "always" be the case that
current-buffer is the specified buffer and selected-window displays
that buffer.


        Stefan

Re: managing windows in two frames

[martin rudalics]

 > Both needs exist: to work in older Emacsen, and to be "clean and
 > simple".  I care more about the second one.

So use `display-buffer-function' only where and when
`display-buffer-overriding-action' is undefined.

 > I know, which is why with-inhibit-window-changes would probably not
 > really prevent changing windows; instead it would work hard to limit
 > window changes to those that can be fully reverted by
 > save-window-excursion.

This might prove difficult when the selected frame is special (small,
dedicated).

martin

Re: managing windows in two frames

[Stefan Monnier]

> This might prove difficult when the selected frame is special (small,
> dedicated).

I know.  E.g. a minibuffer-only frame.


        Stefan

Re: managing windows in two frames

[Stephen Leake]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> (defun sal-move-to-other-frame ()
>>   "Move current buffer to a window in another frame."
>>   (interactive)
>>   (let ((buffer (current-buffer)))
>>     (switch-to-prev-buffer nil 'bury)
>>     (let ((display-buffer-overriding-action
>> 	   '((display-buffer-reuse-frame buffer display-buffer-pop-up-frame)
>> 	     . '((reusable-frames . visible)))))   ;; reuse a window in other frame
>>       (display-buffer buffer))))
>
> Don't let-bind display-buffer-overriding-action here.
> Just pass the relevant args to display-buffer.
> display-buffer-overriding-action is only for use when you don't have
> direct control over the call(s) to display-buffer.

Ah, right; the ACTION arg to display-buffer overrides
display-buffer-base-action, which I have set.

-- 
-- Stephe