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.