bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Drew Adams]

emacs -Q

In *scratch* evaluate:
(setq special-display-regexps '("[ ]?[*][^*]+[*]"))

C-x 5 b *scratch*

A new frame should be created, showing *scratch*.  None is.
Without making *scratch* special-display-p, *scratch* is shown,
correctly, in a separate frame.

Similarly, (pop-to-buffer "*scratch*" t) does not pop to *scratch*
in another window.  (display-buffer-other-frame "*scratch*"),
likewise, does not display the buffer in another frame.

If the buffer is not special-display-p then another new
frame/window is used, as it should be.  If it is
special-display-p then this should still be the case, but the
action instead becomes a no-op.

Special-display-p implies that the window is dedicated to the
buffer.  It does not imply that the buffer is somehow "dedicated"
to the window (such a notion does not exist).  A special-display
buffer should be shown in another frame/window when other-frame
is called for.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-11 on ODIEONE
Bzr revision: 116410 lekktu@gmail.com-20140211204823-l9l2s6tktfitq266
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[martin rudalics]

 > emacs -Q
 >
 > In *scratch* evaluate:
 > (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
 >
 > C-x 5 b *scratch*
 >
 > A new frame should be created, showing *scratch*.  None is.
 > Without making *scratch* special-display-p, *scratch* is shown,
 > correctly, in a separate frame.
 >
 > Similarly, (pop-to-buffer "*scratch*" t) does not pop to *scratch*
 > in another window.  (display-buffer-other-frame "*scratch*"),
 > likewise, does not display the buffer in another frame.
 >
 > If the buffer is not special-display-p then another new
 > frame/window is used, as it should be.  If it is
 > special-display-p then this should still be the case, but the
 > action instead becomes a no-op.
 >
 > Special-display-p implies that the window is dedicated to the
 > buffer.  It does not imply that the buffer is somehow "dedicated"
 > to the window (such a notion does not exist).  A special-display
 > buffer should be shown in another frame/window when other-frame
 > is called for.

Bug#9532?  Can you look into `display-buffer--special-action' to see
what goes wrong?

martin

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Drew Adams]

> Can you look into `display-buffer--special-action' to see
> what goes wrong?

I don't understand `display-buffer--special-action'.  If you
send me a recipe of what you would like tried, I will follow it
and let you know what I see.

I provided a simple recipe from -Q to repro the problem, so
you too could follow your recipe.  I will be glad to do so as
well in my environment (MS Windows 7, and Cygwin installed),
in case the platform makes a difference.

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[martin rudalics]

 >> Can you look into `display-buffer--special-action' to see
 >> what goes wrong?
 >
 > I don't understand `display-buffer--special-action'.

Me neither.  Sometimes Stefan's programming style is too sophisticated
for me.  I thought you might understand it better because I completely
forgot how this should be handled.

 > If you
 > send me a recipe of what you would like tried, I will follow it
 > and let you know what I see.
 >
 > I provided a simple recipe from -Q to repro the problem, so
 > you too could follow your recipe.  I will be glad to do so as
 > well in my environment (MS Windows 7, and Cygwin installed),
 > in case the platform makes a difference.

I can reproduce the behavior as you described it.  But this doesn't help
me in understanding it.

martin

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Drew Adams]

> I can reproduce the behavior as you described it.
> But this doesn't help me in understanding it.

Thanks for trying.  I guess we're in the same boat in that regard.

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>> In *scratch* evaluate:
>> (setq special-display-regexps '("[ ]?[*][^*]+[*]"))
>>
>> C-x 5 b *scratch*
>>
>> A new frame should be created, showing *scratch*.  None is.
>> Without making *scratch* special-display-p, *scratch* is shown,
>> correctly, in a separate frame.

I can reproduce this in Emacs 28, but reading the doc string of that
variable, I'm not at all sure whether this is supposed to work this way
or not.  And:

[...]

> Bug#9532?  Can you look into `display-buffer--special-action' to see
> what goes wrong?

... it seems this variable was made obsolete in Emacs 24.3?  Martin, is
this a bug, or is this something the user just has to use
`display-buffer-alist' instead to achieve?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[martin rudalics]

 > ... it seems this variable was made obsolete in Emacs 24.3?  Martin, is
 > this a bug, or is this something the user just has to use
 > `display-buffer-alist' instead to achieve?

Crystal ball tells me that it's caused by this line in
`display-buffer--special-action':

            (list (list #'display-buffer-reuse-window

Maybe Stefan can tell us more.

martin

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

martin rudalics [2021-09-06 16:08:11] wrote:
>> ... it seems this variable was made obsolete in Emacs 24.3?

At the same time as `special-display-regexps`.

>> Martin, is this a bug, or is this something the user just has to use
>> `display-buffer-alist' instead to achieve?
>
> Crystal ball tells me that it's caused by this line in
> `display-buffer--special-action':
>
>            (list (list #'display-buffer-reuse-window
>
> Maybe Stefan can tell us more.

Hmmm `M-x trace-function RET display-buffer-reuse-window RET`
tells me that when we do (pop-to-buffer "*scratch*" t), that function
correctly receives `inhibit-same-window` and obeys it:

    1 -> (display-buffer-reuse-window #<buffer *scratch*> ((inhibit-same-window . t)))
    1 <- display-buffer-reuse-window: nil

Same for `C-x 5 b`:

    1 -> (display-buffer-reuse-window #<buffer *scratch*> ((reusable-frames . 0) (inhibit-same-window . t)))
    1 <- display-buffer-reuse-window: nil

So it seems this is not the culprit.


        Stefan

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[martin rudalics]

 > So it seems this is not the culprit.

The "culprit" is `special-display-popup-frame' with its

     (let ((window (get-buffer-window buffer 0)))

and it worked this way already in the past century (it had

   (let ((window (get-buffer-window buffer t)))

then).  All this is explained in the doc-string of
`switch-to-buffer-other-frame' as

   By default, if the buffer is already
   displayed (even in the current frame), that window is selected.
   If the buffer isn't displayed in any frame, a new frame is popped
   up and the buffer is displayed there.

So the bug seems rather that C-x 5 b with `special-display-regexps' nil
pops up a new frame when the buffer already appears on some frame.

martin

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[martin rudalics]

 > So the bug seems rather that C-x 5 b with `special-display-regexps' nil
 > pops up a new frame when the buffer already appears on some frame.

Summarizing:

C-x 5 b with `special-display-regexps' uncustomized behaves as expected
with one minor inaccuracy:

- The doc-string says that "By default, if the buffer is already
   displayed (even in the current frame), that window is selected."

- The manual says more accurately that "If the specified buffer is
   already displayed in another window, in any frame on the current
   terminal, this switches to that window instead of creating a new
   frame.  However, the selected window is never used for this."

So if *scratch* is displayed in the selected window, that window is not
used but the doc-string doesn't tell that.

C-x 5 b with `special-display-regexps' customized in a way that matches
the name of the buffer to switch to, behaves as advertised.  In the case
at hand, it assumes that if *scratch* already appears in a window,
*scratch* has been "displayed specially" in that window and consequently
reuses that window as prescribed.  Popping up a separate window or frame
for *scratch* would be wrong.

Concluding: This is "not a bug" and all statements made in the original
report are based on a misunderstanding of the now obsolete concept of
the special display of buffers.  It's probably about time to remove that
code from base.

martin

bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

> C-x 5 b with `special-display-regexps' customized in a way that matches
> the name of the buffer to switch to, behaves as advertised.  In the case
> at hand, it assumes that if *scratch* already appears in a window,
> *scratch* has been "displayed specially" in that window and consequently
> reuses that window as prescribed.  Popping up a separate window or frame
> for *scratch* would be wrong.

Yes, I think that sounds correct to me.

> Concluding: This is "not a bug" and all statements made in the original
> report are based on a misunderstanding of the now obsolete concept of
> the special display of buffers.  It's probably about time to remove that
> code from base.

It was made obsolete in 24.3...  how far have we gotten in removing
obsolete things now?  23.x?  So perhaps we should start removing 24.x
things in the Emacs 29 cycle.

Anyway, since this seems like it's working as designed, I'm closing this
bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16767: [External] : bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Drew Adams]

1. From the bug report:

  (display-buffer-other-frame "*scratch*"), likewise,
  does not display the buffer in another frame.

From the doc of `display-buffer-other-frame':

 This function attempts to look for a window
 displaying BUFFER, on all the frames on the
 current terminal, skipping the selected window;
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 if that fails, it pops up a new frame.

That's not what happens.  It's not skipping the
selected frame.  The doc is unequivocal.

2. From the bug report:

  Similarly, (pop-to-buffer "*scratch*" t) does
  not pop to *scratch* in another window.

From the doc of `pop-to-buffer':

 ACTION is t if called interactively with a
 prefix argument, which means to pop to a
 window other than the selected one
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 even if the buffer is already displayed
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 in the selected window.
 ^^^^^^^^^^^^^^^^^^^^^^

That's not what happens.  It's not using a
window other than the selected one, with an
ACTION value of `t' (including interactively
with a prefix arg).  Again, the doc's crystal
clear - no ifs, ands, or buts.

Even if you have two frames with `*scratch*',
and you try `C-u pop-to-buffer *scratch*' in
one of them, the other one is NOT selected.

3. The doc string of `switch-to-buffer-other-frame'
says nothing about not switching to the buffer
in another frame.  It just says, clearly, that
the command switches to the buffer in another
frame - unconditionally.

In the Elisp manual it's even clearer:

 If the specified buffer is already displayed in
 another window, in any frame on the current
 terminal, this switches to that window instead of
 creating a new frame.
 However, the selected window is never used for this.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The doc, everywhere, for all 3 of the commands
reported by the bug report, says unequivocally
that in the cases described another window
(in another frame) is used, even if it has to
be created.

Is the doc wrong everywhere?  Do you think the
_intention_ of someone using a `C-x 5' prefix is
ever to NOT use another frame?  IMHO, it's the
implementation that's bugged, not the doc and
not the intention behind `C-x 5'.

And it's not surprising that such a bug could go
unreported for a long time.  I suspect that most
users don't use `other-frame' commands that often.
But some users use them a lot.  Ignoring such use
cases and their users doesn't help.

___

The bug report is one thing.  Things got a bit
turned around by some translating to talking
about the implementation in the thread, I think. ;-)
What matters is the behavior for users.  `C-x 5'
is all about using another frame.  And the doc
of these commands specifies clearly what the
expected and intended behavior is.

bug#16767: [External] : bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[martin rudalics]

 > 1. From the bug report:
 >
 >    (display-buffer-other-frame "*scratch*"), likewise,
 >    does not display the buffer in another frame.

It does so by default.  You are using an option whose purpose is to
override the default behavior.

 >  From the doc of `display-buffer-other-frame':
 >
 >   This function attempts to look for a window
 >   displaying BUFFER, on all the frames on the
 >   current terminal, skipping the selected window;
 >                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >   if that fails, it pops up a new frame.
 >
 > That's not what happens.  It's not skipping the
 > selected frame.  The doc is unequivocal.

The doc specifies the default behavior.  You are using an option that
overrides the default behavior.

 > 2. From the bug report:
 >
 >    Similarly, (pop-to-buffer "*scratch*" t) does
 >    not pop to *scratch* in another window.
 >
 >  From the doc of `pop-to-buffer':
 >
 >   ACTION is t if called interactively with a
 >   prefix argument, which means to pop to a
 >   window other than the selected one
 >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >   even if the buffer is already displayed
 >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 >   in the selected window.
 >   ^^^^^^^^^^^^^^^^^^^^^^
 >
 > That's not what happens.  It's not using a
 > window other than the selected one, with an
 > ACTION value of `t' (including interactively
 > with a prefix arg).  Again, the doc's crystal
 > clear - no ifs, ands, or buts.

The doc specifies the default behavior.  You are using an option that
overrides the default behavior.

 > Even if you have two frames with `*scratch*',
 > and you try `C-u pop-to-buffer *scratch*' in
 > one of them, the other one is NOT selected.

I have no idea what `C-u pop-to-buffer *scratch*' means.  But if, with
emacs -Q, I evaluate

(pop-to-buffer "*scratch*" t)

it will pop to *scratch* in another window.

 > 3. The doc string of `switch-to-buffer-other-frame'
 > says nothing about not switching to the buffer
 > in another frame.  It just says, clearly, that
 > the command switches to the buffer in another
 > frame - unconditionally.
 >
 > In the Elisp manual it's even clearer:
 >
 >   If the specified buffer is already displayed in
 >   another window, in any frame on the current
 >   terminal, this switches to that window instead of
 >   creating a new frame.
 >   However, the selected window is never used for this.
 >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Because you are using an option that overrides the default behavior.

 > The doc, everywhere, for all 3 of the commands
 > reported by the bug report, says unequivocally
 > that in the cases described another window
 > (in another frame) is used, even if it has to
 > be created.

Unless you are using an option that overrides the default behavior.

 > Is the doc wrong everywhere?  Do you think the
 > _intention_ of someone using a `C-x 5' prefix is
 > ever to NOT use another frame?  IMHO, it's the
 > implementation that's bugged, not the doc and
 > not the intention behind `C-x 5'.
 >
 > And it's not surprising that such a bug could go
 > unreported for a long time.  I suspect that most
 > users don't use `other-frame' commands that often.
 > But some users use them a lot.  Ignoring such use
 > cases and their users doesn't help.
 >
 > ___
 >
 > The bug report is one thing.  Things got a bit
 > turned around by some translating to talking
 > about the implementation in the thread, I think. ;-)
 > What matters is the behavior for users.  `C-x 5'
 > is all about using another frame.  And the doc
 > of these commands specifies clearly what the
 > expected and intended behavior is.

You are using an obsolete option whose purpose is to override the
documented behavior so you are getting what you asked for.  Please stop
calling that a bug if you want that your arguments are taken seriously.

Your posting is a strong argument for removing `special-display-regexps'
and its ilk ASAP.

martin

bug#16767: [External] : bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Drew Adams]

> It does so by default.  You are using an option
> whose purpose is to override the default behavior.
> ...
> The doc specifies the default behavior.  You are
> using an option that overrides the default behavior.
> ...
> The doc specifies the default behavior.  You are
> using an option that overrides the default behavior.
> ...
> Because you are using an option that overrides the
> default behavior.
> ...
> Unless you are using an option that overrides the
> default behavior.
> ...
> You are using an obsolete option whose purpose is
> to override the documented behavior so you are
> getting what you asked for.

Your post prompted me to look again at the doc of
the option in question.  I guess you're right.

Originally the doc didn't have this part (below),
but it was present in the release (24) where I
filed the bug.  Sorry for not paying more
attention to this:

  If this variable appears "not to work", because
  you added a name to it but the corresponding
  buffer is displayed in the selected window,
  look at the values of ‘same-window-buffer-names’
  and ‘same-window-regexps’.  Those variables take
  precedence over this one.

My value of those `same-window-*' options is nil.
I would think that that would mean NOT imposing
ANY behavior of keeping to the same window, which
is what I thought (think?) that paragraph is about.

[BTW, that text seems to be boilerplate from
`special-display-buffer-names'.  In the regexps
context it should perhaps not say "you added a
name" but instead "you added a regexp".]

Assuming that it's that paragraph that you're
referring to, then OK, I missed that.  Otherwise,
I find nothing in any of the doc that suggests
that I'm "using an option that overrides the
default behavior" in a way that specifies not
using a separate frame.

You can say that the `special-display-*' options
override default behavior, and of course they do.
But nothing says that they override THAT behavior,
of using a separate frame.  Nothing in the doc,
AFAICT.

All they do is say that the given buffers use
frames with particular frame parameters.  They
say nothing at all about the use of a same frame
or a different frame.  And that means (should
mean) that the default behavior described for
the functions cited should remain the case,
except for the behavior (e.g. frame parameters)
prescribed by the `special-display-*' options.
Those options say nothing at all about using
another or the same frame.  They say nothing at
all about `C-x 5' behavior.

And if those `same-window-*' options really are
the solution and the cause of the problem ("not
working"), then I don't see how someone could
customize them to "fix" the (bad, IMO) behavior
reported in this bug. Aren't those options only
about making the _same_ window be used, whereas
what would help here would be the opposite?

What's needed is a way to NOT have prefix key
`C-x 5' use the same window for some specified
set of buffers.  Or (better) to have `C-x 5'
keys NOT use the same window for ANY buffers.
___

Lars's closing of sibling bug #10135 spoke to
the problem/bug as well.  Stefan pretty much
agreed with me there, I think, that the behavior
is essentially bugged (problematic; not what a
user of the option would expect/want).  He said
that _after_ I'd already agreed with you (Martin)
that the bug could be closed.

His point was valid, I think:

  The fact that it's not new doesn't change
  the fact that you dislike this behavior,
  so it's not a reason to close the bug.

(Since then, I've personally switched
`C-x 5 2' to my command `clone-frame'.)

Stefan said this about `C-x 5 2': 

  As you know I use a similar setup to yours
  so I have gone through similar thoughts.
  I haven't actually tried to make C-x 5 2
  "obey" special-display-regexps, but if
  someone wants to try it, here are some
  things to consider:

  . The default behavior for special-display-*
  is to reuse any window that already
  displays the buffer, so in order to make
  C-x 5 2 meaningful we'd clearly want to skip
  this part of the usual special-display-*
  behavior.

  . Maybe C-x 5 2 should be more like "clone
  frame" instead, i.e. don't pay attention to
  special-display-* but instead try to
  reproduce the existing frame (including
  dedicatedness of the window it displays).
  This opens the question of what to do when
  the selected frame has several windows, of course.

These 2 bugs are closed.  `special-display-*'
remains extremely useful and simple.  It would
be good to "fix" these (minor) oversights, but
so be it.
___

Both Emacs life and real life have their limits.
Apart from testing with `emacs -Q', I'm stuck in
Emacs 26 so far and for now - and maybe forever.
The minibuffer's been locked up (down?) in ways
that make Emacs essentially unusable for me.
It's been a fun ride, though.

On n'arrete pas le progres.

bug#16767: [External] : bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[martin rudalics]

 > You can say that the `special-display-*' options
 > override default behavior, and of course they do.
 > But nothing says that they override THAT behavior,
 > of using a separate frame.  Nothing in the doc,
 > AFAICT.

You've been customizing the option `special-display-regexps' which
specifies a

   List of regexps saying which buffers should be displayed specially.

in a way to display *scratch* specially.  The doc-string of that option
continues saying that

   Displaying a buffer with `display-buffer' or `pop-to-buffer', if
   any regexp in this list matches its name, displays it specially
   using `special-display-function'.  `special-display-popup-frame'
   \(the default for `special-display-function') usually displays
   the buffer in a separate frame made with the parameters specified
   by `special-display-frame-alist'.

and since you have not customized `special-display-function' and the
doc-string of `special-display-popup-frame' tells to

   Pop up a frame displaying BUFFER and return its window.
   If BUFFER is already displayed in a visible or iconified frame,
   raise that frame.

C-x 5 b which runs `switch-to-buffer-other-frame' whose doc-string says

   This uses the function `display-buffer' as a subroutine to
   display the buffer; see its documentation for additional
   customization information.

uses the selected window which displays *scratch* already and makes sure
that its frame is risen.

 > All they do is say that the given buffers use
 > frames with particular frame parameters.  They
 > say nothing at all about the use of a same frame
 > or a different frame.  And that means (should
 > mean) that the default behavior described for
 > the functions cited should remain the case,
 > except for the behavior (e.g. frame parameters)
 > prescribed by the `special-display-*' options.
 > Those options say nothing at all about using
 > another or the same frame.

The doc-string of `special-display-popup-frame' says that.

 > They say nothing at
 > all about `C-x 5' behavior.

The doc-string of `switch-to-buffer-other-frame' says that.

 > What's needed is a way to NOT have prefix key
 > `C-x 5' use the same window for some specified
 > set of buffers.  Or (better) to have `C-x 5'
 > keys NOT use the same window for ANY buffers.

The default behavior does that.  You override it with your
customizations.

 >    The default behavior for special-display-*
 >    is to reuse any window that already
 >    displays the buffer, so in order to make
 >    C-x 5 2 meaningful we'd clearly want to skip
 >    this part of the usual special-display-*
 >    behavior.

So you were aware of the fact that C-x 5 2 behaves like that all the
time and yet insisted that our code and/or docs are wrong?  Do you ever
think that going through your bug reports takes peoples' time?

martin

bug#16767: [External] : bug#16767: 24.3.50; `C-x 5 b' for special-display buffers

[Drew Adams]

> since you have not customized `special-display-function' and the
> doc-string of `special-display-popup-frame' tells to
> 
>  Pop up a frame displaying BUFFER and return its window.
>  If BUFFER is already displayed in a visible or iconified frame,
>  raise that frame.

Yes, that seems to solve the mystery.  Thx.
There's no exception for whether BUFFER is in
the selected window.

Whether that behavior makes much sense when the
buffer is in the selected window and the command
is on `C-x 5' is maybe something else.

In any case, the bug is closed.

>Stefan> The default behavior for special-display-*
>Stefan> is to reuse any window that already
>Stefan> displays the buffer, so in order to make
>Stefan> C-x 5 2 meaningful we'd clearly want to skip
>Stefan> this part of the usual special-display-*
>Stefan> behavior.
> 
> So you were aware of the fact that C-x 5 2 behaves like that all the
> time and yet insisted that our code and/or docs are wrong?  Do you ever
> think that going through your bug reports takes peoples' time?

It was not obvious to me that this is the
intended behavior.

I still don't think it's the best behavior.
IMHO, `C-x 5' should win, and I think users
would generally expect that.  It doesn't.

And that's ultimately documented.  You've dug
down into the labyrinth and found a doc string
that documents the behavior.  Good.

As for things not being obviously the intended
behavior, you yourself wrote:

 > I can reproduce the behavior as you described it.
 > But this doesn't help me in understanding it.

Please forgive others less intimate with this
code than you.