bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Jens Lechtenboerger]

Hi there,

I fail to get display-buffer-alist working.

Recipe starting from 'emacs -Q':
Eval this expression:
(customize-set-variable
 'display-buffer-alist
 '(("\\*shell\\*"
    . (display-buffer-pop-up-frame . '((reusable-frames . t))))))
M-x shell
A shell frame opens as expected.
M-x shell
A new frame is opened, while I expected the existing one to be
reused.

Actually, I'm sure that I do not understand the documentation for
display-buffer (redirected from display-buffer-alist).  Maybe that
is a separate bug.

In previous versions of Emacs, I used special-display-buffer-names,
which is obsolete now and points to the variable used above,
display-buffer-alist.  It would be great if the documentation for
that variable explained what to do.  In particular, I would like the
frame to be special/dedicated such that it disappears if the buffer
is killed.  Is that lack of documentation a separate bug?

Best wishes
Jens


In GNU Emacs 26.0.50 (build 1, x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2017-02-24 built on debian-8
Repository revision: 91932fff1ded8ed3b4d39dd06891f26960153b9e

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 > I fail to get display-buffer-alist working.
 >
 > Recipe starting from 'emacs -Q':
 > Eval this expression:
 > (customize-set-variable
 >   'display-buffer-alist
 >   '(("\\*shell\\*"
 >      . (display-buffer-pop-up-frame . '((reusable-frames . t))))))
 > M-x shell
 > A shell frame opens as expected.
 > M-x shell
 > A new frame is opened, while I expected the existing one to be
 > reused.

Please try with

(customize-set-variable
  'display-buffer-alist
  '(("\\*shell\\*"
     (display-buffer-reuse-window display-buffer-pop-up-frame)
     (reusable-frames . t))))

 > Actually, I'm sure that I do not understand the documentation for
 > display-buffer (redirected from display-buffer-alist).  Maybe that
 > is a separate bug.

I think that

  -- Function: display-buffer-pop-up-frame buffer alist
      This function creates a new frame, and displays the buffer in that
      frame's window.

is quite clear in the sense that it does not talk about reusing windows
or frames.  But please feel free to suggest improvements.

 > In previous versions of Emacs, I used special-display-buffer-names,
 > which is obsolete now and points to the variable used above,
 > display-buffer-alist.  It would be great if the documentation for
 > that variable explained what to do.  In particular, I would like the
 > frame to be special/dedicated such that it disappears if the buffer
 > is killed.  Is that lack of documentation a separate bug?

Please read also this

      If ALIST contains a `pop-up-frame-parameters' entry, the associated
      value is added to the newly created frame's parameters.

martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Jens Lechtenboerger]

On 2017-03-03, martin rudalics wrote:

> Please try with
>
> (customize-set-variable
>  'display-buffer-alist
>  '(("\\*shell\\*"
>     (display-buffer-reuse-window display-buffer-pop-up-frame)
>     (reusable-frames . t))))

Yes, that does it.

> I think that
>
>  -- Function: display-buffer-pop-up-frame buffer alist
>      This function creates a new frame, and displays the buffer in that
>      frame's window.
>
> is quite clear in the sense that it does not talk about reusing windows
> or frames.  But please feel free to suggest improvements.

Indeed.  Nevertheless that function seemed to be the closest
candidate coming from the documentation on obsolete functionality
for special frames.

> Please read also this
>
>      If ALIST contains a `pop-up-frame-parameters' entry, the associated
>      value is added to the newly created frame's parameters.

I did.  At what are you hinting?  I believe that for users this text
is not of much help as the Emacs manual contains next to nothing on
frame parameters but points to the elisp manual.

Thanks for your help
Jens

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 > Indeed.  Nevertheless that function seemed to be the closest
 > candidate coming from the documentation on obsolete functionality
 > for special frames.

Please suggest better documentation then.

 >> Please read also this
 >>
 >>       If ALIST contains a `pop-up-frame-parameters' entry, the associated
 >>       value is added to the newly created frame's parameters.
 >
 > I did.  At what are you hinting?  I believe that for users this text
 > is not of much help as the Emacs manual contains next to nothing on
 > frame parameters but points to the elisp manual.

The text is from the Elisp manual and I hinted at it because I thought
there was a frame parameter for controlling dedicatedness.  I was wrong
- there is no such parameter.  You rather have to set the variable
‘display-buffer-mark-dedicated’ to non-nil or bind it around the
‘display-buffer’ call.  That's very ugly.  I think we should provide an
alist entry like the `reusable-frames' one to control the dedicateness
of the window used.

martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Jens Lechtenboerger]

On 2017-03-03, martin rudalics wrote:

>> Indeed.  Nevertheless that function seemed to be the closest
>> candidate coming from the documentation on obsolete functionality
>> for special frames.
>
> Please suggest better documentation then.

I'll try once I know how to create special/dedicated frames.

Best wishes
Jens

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

 > I'll try once I know how to create special/dedicated frames.

Impossible since the "fix" for Bug#15133.  Apparently no one used this
in the past four years.  Please apply the attached patch and try again.
The following example works here now as intended.

(customize-set-variable
  'display-buffer-alist
  '(("\\*text\\*"
     (display-buffer-reuse-window display-buffer-pop-up-frame)
     (reusable-frames . t))))

(setq display-buffer-mark-dedicated t)

(display-buffer (get-buffer-create "*text*"))

(kill-buffer "*text*")

martin

[-- Attachment #2: window.el.diff --]
[-- Type: text/plain, Size: 1962 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index 358d7bc..4fd1c10 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5986,7 +5986,10 @@ display-buffer-record-window
 shown in the window, that buffer's window start and window point,
 and the window's height.  The third element is the window
 selected at the time the parameter was created.  The fourth
-element is BUFFER."
+element is BUFFER.
+
+When TYPE equals `window' or `frame' this function also clears
+the list of previous buffers of WINDOW."
   (cond
    ((eq type 'reuse)
     (if (eq (window-buffer window) buffer)
@@ -6018,12 +6021,14 @@ display-buffer-record-window
     ;; WINDOW has been created on an existing frame.
     (set-window-parameter
      window 'quit-restore
-     (list 'window 'window (selected-window) buffer)))
+     (list 'window 'window (selected-window) buffer))
+    (set-window-prev-buffers window nil))
    ((eq type 'frame)
     ;; WINDOW has been created on a new frame.
     (set-window-parameter
      window 'quit-restore
-     (list 'frame 'frame (selected-window) buffer)))))
+     (list 'frame 'frame (selected-window) buffer)))
+   (set-window-prev-buffers window nil)))

 (defcustom display-buffer-function nil
   "If non-nil, function to call to handle `display-buffer'.
@@ -6643,11 +6648,9 @@ window--display-buffer
     (display-buffer-record-window type window buffer)
     (unless (eq buffer (window-buffer window))
       (set-window-dedicated-p window nil)
-      (set-window-buffer window buffer)
-      (when dedicated
-	(set-window-dedicated-p window dedicated))
-      (when (memq type '(window frame))
-	(set-window-prev-buffers window nil)))
+      (set-window-buffer window buffer))
+    (when (and dedicated (memq type '(window frame)))
+      (set-window-dedicated-p window dedicated))
     (let ((quit-restore (window-parameter window 'quit-restore))
 	  (height (cdr (assq 'window-height alist)))
 	  (width (cdr (assq 'window-width alist)))

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Drew Adams]

>  > I'll try once I know how to create special/dedicated frames.
> 
> Impossible since the "fix" for Bug#15133.  Apparently no one
> used this in the past four years.

Huh? I use special/dedicated frames all day long, everyday, as
you well know.

But I use `special-display-regexps', `special-display-buffer-names'
(including function value), `special-display-alist', etc.
Thank goodness they still work, without problem.  Without them,
I'd likely have to stop using Emacs.

If there were a clear, just-as-simple, just-as-succinct,
alternative way to accomplish the same thing, and if I were
forced to use it instead of what (still) works for all Emacs
versions (`special-display-*'), then I'd use it.

It wouldn't be convenient, because I use multiple Emacs
releases everyday, but if it were just as simple and I had no
choice then I would likely use it (in addition to using
`special-display-*' for older releases).

But AFAIK there is NO clear and just-as-simple, alternative
way to get the `special-display-*' behavior.  That's too bad.

What should be done, IMHO, instead of deprecating such
simple, useful, and straightforward user knobs, is to
continue to support (and even promote) them, even if they
might now be reimplemented using more complex mechanisms.

We should not lose these useful constructs.  They work fine
still.  They should continue to just work, as always.
Adding additional bells and whistles to Emacs should not
remove this convenient behavior and its simple user-level
constructs.

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Jens Lechtenboerger]

> Impossible since the "fix" for Bug#15133.  Apparently no one used this
> in the past four years.

I am using that via special-display-* variables (as also explained
by Drew Adams).  Only by chance did I see that those were declared
obsolete a long time ago.

> Please apply the attached patch and try again.
> The following example works here now as intended.
>
> (customize-set-variable
>   'display-buffer-alist
>   '(("\\*text\\*"
>      (display-buffer-reuse-window display-buffer-pop-up-frame)
>      (reusable-frames . t))))
>
> (setq display-buffer-mark-dedicated t)
>
> (display-buffer (get-buffer-create "*text*"))

A new frame appears ...

> (kill-buffer "*text*")

but does not disappear.

Best wishes
Jens

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 > The following example works here now as intended.
 >
 > (customize-set-variable
 >   'display-buffer-alist
 >   '(("\\*text\\*"
 >      (display-buffer-reuse-window display-buffer-pop-up-frame)
 >      (reusable-frames . t))))
 >
 > (setq display-buffer-mark-dedicated t)
 >
 > (display-buffer (get-buffer-create "*text*"))
 >
 > (kill-buffer "*text*")

Did you apply the patch?  After that you have to rebuild emacs because
window.el is preloaded.  Or recompile window.el which, however, provides
the functionality only for that session.  If neither of these help, then
please tell me the value of `window-dedicated-p' in the window showing
*text* - it's "t" here.

martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

Can some kind soul please apply the attached patch to master?  The
commit message is


In `window--display-buffer' fix behavior reported in Bug#25946

* lisp/window.el (window--display-buffer): Set the dedicated
status of the window used and clear its history of previous
buffers also for the case that the window already shows the
buffer to be displayed.  (Bug#25946)


Many thanks in advance, martin

[-- Attachment #2: window.el.diff --]
[-- Type: text/plain, Size: 856 bytes --]

diff --git a/lisp/window.el b/lisp/window.el
index 358d7bc..5050243 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -6643,11 +6643,11 @@ window--display-buffer
     (display-buffer-record-window type window buffer)
     (unless (eq buffer (window-buffer window))
       (set-window-dedicated-p window nil)
-      (set-window-buffer window buffer)
-      (when dedicated
-	(set-window-dedicated-p window dedicated))
-      (when (memq type '(window frame))
-	(set-window-prev-buffers window nil)))
+      (set-window-buffer window buffer))
+    (when dedicated
+      (set-window-dedicated-p window dedicated))
+    (when (memq type '(window frame))
+      (set-window-prev-buffers window nil))
     (let ((quit-restore (window-parameter window 'quit-restore))
 	  (height (cdr (assq 'window-height alist)))
 	  (width (cdr (assq 'window-width alist)))

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Stephen Berman]

On Sun, 05 Mar 2017 11:34:33 +0100 martin rudalics <rudalics@gmx.at> wrote:

> Can some kind soul please apply the attached patch to master?  The
> commit message is
>
>
> In `window--display-buffer' fix behavior reported in Bug#25946
>
> * lisp/window.el (window--display-buffer): Set the dedicated
> status of the window used and clear its history of previous
> buffers also for the case that the window already shows the
> buffer to be displayed.  (Bug#25946)
>
>
> Many thanks in advance, martin
>
> diff --git a/lisp/window.el b/lisp/window.el
> index 358d7bc..5050243 100644
> --- a/lisp/window.el
> +++ b/lisp/window.el
> @@ -6643,11 +6643,11 @@ window--display-buffer
>      (display-buffer-record-window type window buffer)
>      (unless (eq buffer (window-buffer window))
>        (set-window-dedicated-p window nil)
> -      (set-window-buffer window buffer)
> -      (when dedicated
> -	(set-window-dedicated-p window dedicated))
> -      (when (memq type '(window frame))
> -	(set-window-prev-buffers window nil)))
> +      (set-window-buffer window buffer))
> +    (when dedicated
> +      (set-window-dedicated-p window dedicated))
> +    (when (memq type '(window frame))
> +      (set-window-prev-buffers window nil))
>      (let ((quit-restore (window-parameter window 'quit-restore))
>  	  (height (cdr (assq 'window-height alist)))
>  	  (width (cdr (assq 'window-width alist)))

I pushed it in your name as commit 702aeca.

Steve Berman

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 > I pushed it in your name as commit 702aeca.

Wonderful.  Thank you very much.  Can you please test whether it DTRT?
Two steps are needed.

(1) With emacs -Q evaluate the following forms one after another:

(customize-set-variable
  'display-buffer-alist
  '(("\\*text\\*"
     (display-buffer-reuse-window display-buffer-pop-up-frame)
     (reusable-frames . t))))

(setq display-buffer-mark-dedicated t)

(display-buffer (get-buffer-create "*text*"))

(kill-buffer "*text*")

After the last step the second frame should disappear.

(2) With emacs -Q evaluate the following forms one after another:

(customize-set-variable
  'display-buffer-alist
  '(("\\*text\\*"
     display-buffer-pop-up-window)))

(display-buffer (get-buffer-create "*text*"))

Now do

C-x o

M-x quit-window

The window showing *text* should disappear.

Thanks, martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> writes:

> > I pushed it in your name as commit 702aeca.
>
> Wonderful.  Thank you very much.  Can you please test whether it DTRT?
> Two steps are needed. [...]

Works as described for me in emacs -Q after rebuilding.


Michael.

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

> Works as described for me in emacs -Q after rebuilding.

Thanks for testing.

martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Stephen Berman]

On Sun, 05 Mar 2017 23:20:21 +0100 Michael Heerdegen <michael_heerdegen@web.de> wrote:

> martin rudalics <rudalics@gmx.at> writes:
>
>> > I pushed it in your name as commit 702aeca.
>>
>> Wonderful.  Thank you very much.  Can you please test whether it DTRT?
>> Two steps are needed. [...]
>
> Works as described for me in emacs -Q after rebuilding.

Same here (I couldn't test till just now).

Steve Berman

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Jens Lechtenboerger]

On 2017-03-06, Stephen Berman wrote:

> On Sun, 05 Mar 2017 23:20:21 +0100 Michael Heerdegen
> <michael_heerdegen@web.de> wrote:
>
>> martin rudalics <rudalics@gmx.at> writes:
>>
>>> > I pushed it in your name as commit 702aeca.
>>>
>>> Wonderful.  Thank you very much.  Can you please test whether it DTRT?
>>> Two steps are needed. [...]
>>
>> Works as described for me in emacs -Q after rebuilding.
>
> Same here (I couldn't test till just now).

And here, many thanks.  (I did not rebuild Emacs in my previous
test.)

However, I'm having problems with LaTeX/AUCTeX [0] output buffers.
I'm currently using this obsolete (but working) setting:
(setq special-display-regexps '(".* output"))

Now, when replacing "\\*text\\*" with ".* output" in the above
recipe, compiling a tex file (C-c C-c), and pressing C-c C-l to
display the LaTeX output, a new frame gets created but is split in
half: The lower half showing the tex source (and containing the
cursor), the upper with output.  I expected the output in the entire
frame.

As this requires AUCTeX, I don't see a simple test case.
Besides, I won't have time for further tests this week.

Here is my basic configuration for emacs -Q (assuming that AUCTeX is
installed from ELPA via list-packages):

(package-initialize)
(load "auctex.el" nil t t)
(customize-set-variable 'display-buffer-alist
			'((".* output"
			   (display-buffer-reuse-window display-buffer-pop-up-frame)
			   (reusable-frames . t))
			  ))
(setq display-buffer-mark-dedicated t)


Best wishes
Jens

[0] https://www.gnu.org/software/auctex/download.html

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Stephen Berman]

On Mon, 06 Mar 2017 10:25:03 +0100 Jens Lechtenboerger <lechten@wi.uni-muenster.de> wrote:

> On 2017-03-06, Stephen Berman wrote:
>
>> On Sun, 05 Mar 2017 23:20:21 +0100 Michael Heerdegen
>> <michael_heerdegen@web.de> wrote:
>>
>>> martin rudalics <rudalics@gmx.at> writes:
>>>
>>>> > I pushed it in your name as commit 702aeca.
>>>>
>>>> Wonderful.  Thank you very much.  Can you please test whether it DTRT?
>>>> Two steps are needed. [...]
>>>
>>> Works as described for me in emacs -Q after rebuilding.
>>
>> Same here (I couldn't test till just now).
>
> And here, many thanks.  (I did not rebuild Emacs in my previous
> test.)
>
> However, I'm having problems with LaTeX/AUCTeX [0] output buffers.
> I'm currently using this obsolete (but working) setting:
> (setq special-display-regexps '(".* output"))
>
> Now, when replacing "\\*text\\*" with ".* output" in the above
> recipe, compiling a tex file (C-c C-c), and pressing C-c C-l to
> display the LaTeX output, a new frame gets created but is split in
> half: The lower half showing the tex source (and containing the
> cursor), the upper with output.  I expected the output in the entire
> frame.

I think this window-splitting is because TeX-recenter-output-buffer
(bound to `C-c C-l') calls `(TeX-pop-to-buffer buffer t t)', which calls
pop-to-buffer with the ACTION argument set to t, which according to
pop-to-buffer's doc string " means to pop to a window other than the
selected one even if the buffer is already displayed in the selected
window".  Maybe AUCTeX should have a user option that can be passed as
the ACTION argument to pop-to-buffer.

Steve Berman

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 > However, I'm having problems with LaTeX/AUCTeX [0] output buffers.
 > I'm currently using this obsolete (but working) setting:
 > (setq special-display-regexps '(".* output"))
 >
 > Now, when replacing "\\*text\\*" with ".* output" in the above
 > recipe, compiling a tex file (C-c C-c), and pressing C-c C-l to
 > display the LaTeX output, a new frame gets created but is split in
 > half: The lower half showing the tex source (and containing the
 > cursor), the upper with output.  I expected the output in the entire
 > frame.
 >
 > As this requires AUCTeX, I don't see a simple test case.
 > Besides, I won't have time for further tests this week.

Since I have no LaTeX building environment installed I suppose it won't
make much sense for me to test.  Is the TeX source not shown with (setq
special-display-regexps '(".* output"))?  Does C-c C-c already display
anything?  What does C-c C-l do to display the output?

martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 >>> Same here (I couldn't test till just now).

Thanks once more for installing and testing.

 > I think this window-splitting is because TeX-recenter-output-buffer
 > (bound to `C-c C-l') calls `(TeX-pop-to-buffer buffer t t)', which calls
 > pop-to-buffer with the ACTION argument set to t, which according to
 > pop-to-buffer's doc string " means to pop to a window other than the
 > selected one even if the buffer is already displayed in the selected
 > window".  Maybe AUCTeX should have a user option that can be passed as
 > the ACTION argument to pop-to-buffer.

But if I do

(customize-set-variable
  'display-buffer-alist
  '(("\\*text\\*"
     (display-buffer-reuse-window display-buffer-pop-up-frame)
     (reusable-frames . t))))

(setq display-buffer-mark-dedicated t)

(pop-to-buffer (get-buffer-create "*text*") t)

everything works as expected.  IIUC something else must interfere here.
How come the TeX source buffer gets "also" displayed on that new frame?

martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Stephen Berman]

On Mon, 06 Mar 2017 18:46:40 +0100 martin rudalics <rudalics@gmx.at> wrote:

>>>> Same here (I couldn't test till just now).
>
> Thanks once more for installing and testing.
>
>> I think this window-splitting is because TeX-recenter-output-buffer
>> (bound to `C-c C-l') calls `(TeX-pop-to-buffer buffer t t)', which calls
>> pop-to-buffer with the ACTION argument set to t, which according to
>> pop-to-buffer's doc string " means to pop to a window other than the
>> selected one even if the buffer is already displayed in the selected
>> window".  Maybe AUCTeX should have a user option that can be passed as
>> the ACTION argument to pop-to-buffer.
>
> But if I do
>
> (customize-set-variable
>  'display-buffer-alist
>  '(("\\*text\\*"
>     (display-buffer-reuse-window display-buffer-pop-up-frame)
>     (reusable-frames . t))))
>
> (setq display-buffer-mark-dedicated t)
>
> (pop-to-buffer (get-buffer-create "*text*") t)
>
> everything works as expected.  IIUC something else must interfere here.
> How come the TeX source buffer gets "also" displayed on that new frame?

Oh, shame on me, I didn't look closely enough before; this is how:

   (defun TeX-recenter-output-buffer (line)
     "Redisplay buffer of TeX job output so that most recent output can be seen.
   The last line of the buffer is displayed on line LINE of the window, or
   at bottom if LINE is nil."
     (interactive "P")
     (let ((buffer (TeX-active-buffer)))
       (if buffer
   	(let ((old-buffer (current-buffer)))
   	  (TeX-pop-to-buffer buffer t t)
   	  (bury-buffer buffer)
   	  (goto-char (point-max))
   	  (recenter (if line
   			(prefix-numeric-value line)
   		      (/ (window-height) 2)))
   	  (TeX-pop-to-buffer old-buffer nil t))    ; <=================
         (message "No process for this document."))))

The second invocation of TeX-pop-to-buffer displays the source buffer;
commenting this out appears to give the result the OP wants.(*)  So to
satisfying both this use case and the one foreseen for this function,
the second invocation could be conditioned on a user option.

(*) I should note that on some tests I made with the second invocation
commented out I got strange results: once or twice, the frame in which
the LaTeX output is displayed did split, showing the *Messages* buffer
below (but with a reduced height); and several times, after killing the
output buffer (and hence its frame), keyboard input was totally blocked,
though mouse input was possible.  I have not been able to reliably
reproduce these effects.

Steve Berman

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 >     	  (TeX-pop-to-buffer old-buffer nil t))    ; <=================
 >           (message "No process for this document."))))
 >
 > The second invocation of TeX-pop-to-buffer displays the source buffer;
 > commenting this out appears to give the result the OP wants.(*)  So to
 > satisfying both this use case and the one foreseen for this function,
 > the second invocation could be conditioned on a user option.

This indeed confers to the behavior described by Jens.  Does the second
argument "nil" mean to stay on the selected frame?

In any case, this order of invocations is asking for trouble when the
output buffer should appear on a separate frame.  The old code worked
around this problem because of the (unsplittable . t) default entry in
‘special-display-frame-alist’.  So Jens probably needs something like

(customize-set-variable
  'display-buffer-alist
  '(("\\*text\\*"
     (display-buffer-reuse-window display-buffer-pop-up-frame)
     (reusable-frames . t))))

(setq display-buffer-mark-dedicated t)
(setq pop-up-frame-alist (cons '(unsplittable . t) pop-up-frame-alist))

(pop-to-buffer (get-buffer-create "*text*") t)

and we are back in the strong grip of global variables, something the
"new" implementation of ‘display-buffer’ was supposed to avoid.  We
can't escape our past.

 > (*) I should note that on some tests I made with the second invocation
 > commented out I got strange results: once or twice, the frame in which
 > the LaTeX output is displayed did split, showing the *Messages* buffer
 > below (but with a reduced height); and several times, after killing the
 > output buffer (and hence its frame), keyboard input was totally blocked,
 > though mouse input was possible.  I have not been able to reliably
 > reproduce these effects.

This is probably due to

commit 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
Author: Noam Postavsky <npostavs@gmail.com>
Date:   Fri Jan 13 19:47:22 2017 -0500

     Don't wait for frame to become visible

Can you try to selectively revert that commit and see whether the
problem persists?

martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Stephen Berman]

On Tue, 07 Mar 2017 10:45:24 +0100 martin rudalics <rudalics@gmx.at> wrote:

>>     	  (TeX-pop-to-buffer old-buffer nil t))    ; <=================
>>           (message "No process for this document."))))
>>
>> The second invocation of TeX-pop-to-buffer displays the source buffer;
>> commenting this out appears to give the result the OP wants.(*)  So to
>> satisfying both this use case and the one foreseen for this function,
>> the second invocation could be conditioned on a user option.
>
> This indeed confers to the behavior described by Jens.  Does the second
> argument "nil" mean to stay on the selected frame?

It's actually passed to pop-to-buffer's ACTION argument, which is hence
nil here.  TeX-pop-to-buffer's signature calls it OTHER-WINDOW, which
was pop-to-buffer's second parameter before it was replaced by ACTION
(TeX-pop-to-buffer is just a wrapper around pop-to-buffer for
compatibility with XEmacs.)

> In any case, this order of invocations is asking for trouble when the
> output buffer should appear on a separate frame.  The old code worked
> around this problem because of the (unsplittable . t) default entry in
> ‘special-display-frame-alist’.  So Jens probably needs something like
>
> (customize-set-variable
>  'display-buffer-alist
>  '(("\\*text\\*"
>     (display-buffer-reuse-window display-buffer-pop-up-frame)
>     (reusable-frames . t))))
>
> (setq display-buffer-mark-dedicated t)
> (setq pop-up-frame-alist (cons '(unsplittable . t) pop-up-frame-alist))
>
> (pop-to-buffer (get-buffer-create "*text*") t)
>
> and we are back in the strong grip of global variables, something the
> "new" implementation of ‘display-buffer’ was supposed to avoid.  We
> can't escape our past.

TeX-recenter-output-buffer could be redefined as follows to get the same
result (according to my tests) without resorting to pop-up-frame-alist:

   (defun TeX-recenter-output-buffer (line)
     "Redisplay buffer of TeX job output so that most recent output can be seen.
   The last line of the buffer is displayed on line LINE of the window, or
   at bottom if LINE is nil."
     (interactive "P")
     (let ((buffer (TeX-active-buffer)))
       (if buffer
   	(let* ((old-buffer (current-buffer))
   	       (frame1 (window-frame (get-buffer-window old-buffer)))
   	       frame2)
   	  (TeX-pop-to-buffer buffer t t)
   	  (setq frame2 (window-frame (get-buffer-window buffer)))
   	  (bury-buffer buffer)
   	  (goto-char (point-max))
   	  (recenter (if line
   			(prefix-numeric-value line)
   		      (/ (window-height) 2)))
   	  (if (eq frame1 frame2)
   	      (TeX-pop-to-buffer old-buffer nil t)
   	    (select-frame-set-input-focus frame1)))
         (message "No process for this document."))))

>> (*) I should note that on some tests I made with the second invocation
>> commented out I got strange results: once or twice, the frame in which
>> the LaTeX output is displayed did split, showing the *Messages* buffer
>> below (but with a reduced height); and several times, after killing the
>> output buffer (and hence its frame), keyboard input was totally blocked,
>> though mouse input was possible.  I have not been able to reliably
>> reproduce these effects.
>
> This is probably due to
>
> commit 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
> Author: Noam Postavsky <npostavs@gmail.com>
> Date:   Fri Jan 13 19:47:22 2017 -0500
>
>     Don't wait for frame to become visible
>
> Can you try to selectively revert that commit and see whether the
> problem persists?

I suppose I could try to revert, but since I can't reliably reproduce
the problems, not seeing them after reverting may not be conclusive.
(For example, so far testing the above redefinition of TeX-pop-to-buffer
has not shown the problems.)

Steve Berman

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 > It's actually passed to pop-to-buffer's ACTION argument, which is hence
 > nil here.  TeX-pop-to-buffer's signature calls it OTHER-WINDOW, which
 > was pop-to-buffer's second parameter before it was replaced by ACTION
 > (TeX-pop-to-buffer is just a wrapper around pop-to-buffer for
 > compatibility with XEmacs.)

I see.

 > TeX-recenter-output-buffer could be redefined as follows to get the same
 > result (according to my tests) without resorting to pop-up-frame-alist:
 >
 >     (defun TeX-recenter-output-buffer (line)
 >       "Redisplay buffer of TeX job output so that most recent output can be seen.
 >     The last line of the buffer is displayed on line LINE of the window, or
 >     at bottom if LINE is nil."
 >       (interactive "P")
 >       (let ((buffer (TeX-active-buffer)))
 >         (if buffer
 >     	(let* ((old-buffer (current-buffer))
 >     	       (frame1 (window-frame (get-buffer-window old-buffer)))

Are you sure old-buffer is displayed in a window here?  Otherwise frame1
is just the frame of the selected window.

 >     	       frame2)
 >     	  (TeX-pop-to-buffer buffer t t)
 >     	  (setq frame2 (window-frame (get-buffer-window buffer)))
 >     	  (bury-buffer buffer)

Why bury it?  To remove it from the selected window?  It might be in
another window.

 >     	  (goto-char (point-max))
 >     	  (recenter (if line
 >     			(prefix-numeric-value line)
 >     		      (/ (window-height) 2)))
 >     	  (if (eq frame1 frame2)
 >     	      (TeX-pop-to-buffer old-buffer nil t)

Why this?

 >     	    (select-frame-set-input-focus frame1)))
 >           (message "No process for this document."))))

It might make sense to redefine that function but I have no idea what it
is supposed to do so I can't really comment on it.

 >> Can you try to selectively revert that commit and see whether the
 >> problem persists?
 >
 > I suppose I could try to revert, but since I can't reliably reproduce
 > the problems, not seeing them after reverting may not be conclusive.
 > (For example, so far testing the above redefinition of TeX-pop-to-buffer
 > has not shown the problems.)

Problems related to that commit might pop up any time with GTK now.  So
if you experience phenomenas similar to the ones you described earlier
please complain immediately.

Thanks, martin

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Stephen Berman]

On Tue, 07 Mar 2017 20:00:14 +0100 martin rudalics <rudalics@gmx.at> wrote:

>> TeX-recenter-output-buffer could be redefined as follows to get the same
>> result (according to my tests) without resorting to pop-up-frame-alist:
>>
>>     (defun TeX-recenter-output-buffer (line)
>>       "Redisplay buffer of TeX job output so that most recent output can be seen.
>>     The last line of the buffer is displayed on line LINE of the window, or
>>     at bottom if LINE is nil."
>>       (interactive "P")
>>       (let ((buffer (TeX-active-buffer)))
>>         (if buffer
>>     	(let* ((old-buffer (current-buffer))
>>     	       (frame1 (window-frame (get-buffer-window old-buffer)))
>
> Are you sure old-buffer is displayed in a window here?  Otherwise frame1
> is just the frame of the selected window.

Normally, TeX-recenter-output-buffer is called (by `C-c C-l') from a
LaTeX source file, which is visited in old-buffer; though if you switch
to another buffer and invoke `M-x TeX-recenter-output-buffer' and the
output buffer exists, it will be displayed together with (by in the same
window and underneath) whatever the current buffer is.

>>     	       frame2)
>>     	  (TeX-pop-to-buffer buffer t t)
>>     	  (setq frame2 (window-frame (get-buffer-window buffer)))
>>     	  (bury-buffer buffer)
>
> Why bury it?  To remove it from the selected window?  It might be in
> another window.

That's in the exisiting definition; I don't know why, and don't see any
difference when I invoke this command with that line commented out.

>>     	  (goto-char (point-max))
>>     	  (recenter (if line
>>     			(prefix-numeric-value line)
>>     		      (/ (window-height) 2)))
>>     	  (if (eq frame1 frame2)
>>     	      (TeX-pop-to-buffer old-buffer nil t)
>
> Why this?

This is to get the current standard behavior described above, i.e. in
the same frame with source buffer above and output buffer below.

>>     	    (select-frame-set-input-focus frame1)))
>>           (message "No process for this document."))))
>
> It might make sense to redefine that function but I have no idea what it
> is supposed to do so I can't really comment on it.

I'm also not really familiar with the AUCTeX code, so I don't know if
this would cause problems elsewhere.

>>> Can you try to selectively revert that commit and see whether the
>>> problem persists?
>>
>> I suppose I could try to revert, but since I can't reliably reproduce
>> the problems, not seeing them after reverting may not be conclusive.
>> (For example, so far testing the above redefinition of TeX-pop-to-buffer
>> has not shown the problems.)
>
> Problems related to that commit might pop up any time with GTK now.  So
> if you experience phenomenas similar to the ones you described earlier
> please complain immediately.

Will do.

Steve Berman

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[Jens Lechtenboerger]

On 2017-03-07, Stephen Berman wrote:

> On Tue, 07 Mar 2017 10:45:24 +0100 martin rudalics <rudalics@gmx.at> wrote:
>
>> So Jens probably needs something like
>>
>> (customize-set-variable
>>  'display-buffer-alist
>>  '(("\\*text\\*"
>>     (display-buffer-reuse-window display-buffer-pop-up-frame)
>>     (reusable-frames . t))))
>>
>> (setq display-buffer-mark-dedicated t)
>> (setq pop-up-frame-alist (cons '(unsplittable . t) pop-up-frame-alist))
>>
>> (pop-to-buffer (get-buffer-create "*text*") t)

Yes, that works for me.

> TeX-recenter-output-buffer could be redefined as follows to get the same
> result (according to my tests) without resorting to pop-up-frame-alist:
>
>    (defun TeX-recenter-output-buffer (line)
> [...]

Yes, that also works for me.

Best wishes
Jens

bug#25946: 26.0.50; display-buffer ignores ignores reusable-frames in display-buffer-alist

[martin rudalics]

 >>> (customize-set-variable
 >>>   'display-buffer-alist
 >>>   '(("\\*text\\*"
 >>>      (display-buffer-reuse-window display-buffer-pop-up-frame)
 >>>      (reusable-frames . t))))
 >>>
 >>> (setq display-buffer-mark-dedicated t)
 >>> (setq pop-up-frame-alist (cons '(unsplittable . t) pop-up-frame-alist))
 >>>
 >>> (pop-to-buffer (get-buffer-create "*text*") t)
 >
 > Yes, that works for me.
 >
 >> TeX-recenter-output-buffer could be redefined as follows to get the same
 >> result (according to my tests) without resorting to pop-up-frame-alist:
 >>
 >>     (defun TeX-recenter-output-buffer (line)
 >> [...]
 >
 > Yes, that also works for me.

Thank you for checking.  I'm closing this bug.  If you think that the
documentation should be improved, please post concrete suggestions or
(preferably) a patch in a new report.

Thanks to everyone involved, martin