same-window-buffer-names and -regexps

same-window-buffer-names and -regexps

[Luc Teirlinck]

There seems to be an obvious anomaly in the behavior of the
display-buffer - same-window-buffer-names (-regexps) mechanism.  It
works fine for commands such as M-x shell and the like, but what sense
does it make for C-x 4 C-o to behave specially for the buffers in
question?  For these buffers, C-x 4 C-o behaves like C-x b.  If that
were the behavior the user wanted, (s)he would clearly use the easier
and more logical command C-x b.  Same thing for the command C-o in the
buffer menu, which for these buffers is identical to f.  The effect on
C-c C-f in ielm is even worse.  I guess there must be several other
additional situations like this.  This behavior is both inconvenient
and extremely confusing.  Somebody who does not know about these two
variables does not stand the slightest chance of figuring out the
cause of all this strange behavior.

Setting the two variables to nil is no solution, because then M-x
shell and friends malfunction.

One solution would be to have M-x shell and friends check these
variables (instead of having display-buffer do that directly) and
then have these functions pass an appropriate flag to display-buffer.

Sincerely,

Luc.

Re: same-window-buffer-names and -regexps

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> Setting the two variables to nil is no solution, because then M-x
> shell and friends malfunction.
> 
> One solution would be to have M-x shell and friends check these
> variables (instead of having display-buffer do that directly) and
> then have these functions pass an appropriate flag to display-buffer.

That would be a silly solution.

I think the right thing to do is to have `C-x 4 C-o' invoke a command
that binds those variables to nil and calls display-buffer (instead of
invoking display-buffer directly, as it does now).

-Miles
-- 
Come now, if we were really planning to harm you, would we be waiting here, 
 beside the path, in the very darkest part of the forest?

Re: same-window-buffer-names and -regexps

[Luc Teirlinck]

Miles Bader wrote:

   That would be a silly solution.

   I think the right thing to do is to have `C-x 4 C-o' invoke a command
   that binds those variables to nil and calls display-buffer (instead of
   invoking display-buffer directly, as it does now).

OK, I probably did not think things over carefully enough.  C-o in the
buffer menu should also be bound to that new command however.  Also,
ielm-display-working-buffer should bind these two variables to nil
around its call to display-buffer.  The same might be true for
dired-display-file, even though most of these buffers are usually not
visiting files.  I bet there are probably other situations like this,
but these are the ones I can think of right now.

Sincerely,

Luc.

Re: same-window-buffer-names and -regexps

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> OK, I probably did not think things over carefully enough.  C-o in the
> buffer menu should also be bound to that new command however.  Also,
> ielm-display-working-buffer should bind these two variables to nil
> around its call to display-buffer.  The same might be true for
> dired-display-file, even though most of these buffers are usually not
> visiting files.  I bet there are probably other situations like this,
> but these are the ones I can think of right now.

Perhaps the 2nd argument to display-buffer (`NOT-THIS-WINDOW'), should
cause it to ignore those variables; it seems like a natural extension to
me, and it would mean that callers don't have to know about all the
various special variables in order to get this behavior.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: same-window-buffer-names and -regexps

[Luc Teirlinck]

Miles Bader wrote:

   Perhaps the 2nd argument to display-buffer (`NOT-THIS-WINDOW'), should
   cause it to ignore those variables; it seems like a natural extension to
   me, and it would mean that callers don't have to know about all the
   various special variables in order to get this behavior.

Maybe.  I do not know whether we have a complete list of all affected
callers yet and whether all these callers actually want to set
`NOT-THIS-WINDOW' non-nil.  If we bind C-x 4 C-o and C-o in
buffer-menu to a new command, then callers like
ielm-display-working-buffer can call that new command instead of
display-buffer, so that they also do not have to worry about binding
all these variables directly themselves.  I believe that the overhead
of the one extra function call should be be immaterial.

Sincerely,

Luc.

Re: same-window-buffer-names and -regexps

[Stefan Monnier]

> One solution would be to have M-x shell and friends check these
> variables (instead of having display-buffer do that directly) and
> then have these functions pass an appropriate flag to display-buffer.

I like this solution.
When I display-buffer *shell* I generally don't want it to be in the
same window.  The only exception is when I do M-x shell.
The problem with temporarily binding same-window-buffer-names to nil
is that it needs to be done for many different cases (basically
all the cases that do something similar to "select the specified
buffer" and there are many, including in many separate packages
providing some buffe-switching or buffer-listing replacement).


	Stefan

Re: same-window-buffer-names and -regexps

[Richard Stallman]

    Perhaps the 2nd argument to display-buffer (`NOT-THIS-WINDOW'), should
    cause it to ignore those variables; it seems like a natural extension to
    me, and it would mean that callers don't have to know about all the
    various special variables in order to get this behavior.

That seems clean to me, since it will make most of these commands
work right with no further ado.

If after that a few commands still have problems, we can fix those
few next.