switch-to-buffer: for interactive use only

switch-to-buffer: for interactive use only

[Glenn Morris]

Was it really necessary to mark switch-to-buffer "for interactive use
only"? It's a pretty basic command that was used in ~ 800 places in the
Emacs 23.3 sources. The Emacs 23.3 Lisp manual also says "The
@code{switch-to-buffer} function is often used interactively... It is
also used frequently in programs". Isn't there a better way to handle
this than replacing hundreds of calls with `pop-to-buffer-same-window'?

Re: switch-to-buffer: for interactive use only

[Juanma Barranquero]

On Tue, Jul 5, 2011 at 23:40, Glenn Morris <rgm@gnu.org> wrote:

> t's a pretty basic command that was used in ~ 800 places in the
> Emacs 23.3 sources.

On the trunk it generates "only" 471 warnings.

    Juanma

Re: switch-to-buffer: for interactive use only

[Glenn Morris]

>> It's a pretty basic command that was used in ~ 800 places in the
>> Emacs 23.3 sources.
>
> On the trunk it generates "only" 471 warnings.

I grepped wrongly. (I knew the first comment would be something along
these lines.)

Re: switch-to-buffer: for interactive use only

[Juanma Barranquero]

On Wed, Jul 6, 2011 at 01:32, Glenn Morris <rgm@gnu.org> wrote:

> I grepped wrongly. (I knew the first comment would be something along
> these lines.)

;-)

    Juanma

Re: switch-to-buffer: for interactive use only

[Juanma Barranquero]

On Wed, Jul 6, 2011 at 01:32, Glenn Morris <rgm@gnu.org> wrote:

> (I knew the first comment would be something along
> these lines.)

But, seriously, IIUC the intent of Martin's changes, one of the goals
is to help differentiate between user commands and elisp functions;
packages should use functions that express the intent of the code, and
make use of the SPECIFIERS and LABEL args to indicate any non-standard
behavior (that the user can override with display-buffer-alist). I
don't find hard to believe than in many of these 471 cases, what the
code pretends is more akin to `pop-to-buffer-same-window' than to
`switch-to-buffer'.

    Juanma

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

> Was it really necessary to mark switch-to-buffer "for interactive use
> only"? It's a pretty basic command that was used in ~ 800 places in the
> Emacs 23.3 sources.

Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
being typically a user like myself who uses dedicated windows and/or
minibuffer-only frames).  In Emacs-23, I basically redefined
switch-to-buffer as something akin to pop-to-buffer-same-window which
fixes many of those bugs but introduces others.

> Was it really necessary to mark switch-to-buffer "for interactive use
> only"? It's a pretty basic command that was used in ~ 800 places in the
> Emacs 23.3 sources. 

Indeed, the manual needs to be fixed in this respect.

> Isn't there a better way to handle this than replacing hundreds of
> calls with `pop-to-buffer-same-window'?

Not sure what that way would be.


	Stefan

Re: switch-to-buffer: for interactive use only

[Glenn Morris]

Stefan Monnier wrote:

> Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
> being typically a user like myself who uses dedicated windows and/or
> minibuffer-only frames).
[...]
>> Isn't there a better way to handle this than replacing hundreds of
>> calls with `pop-to-buffer-same-window'?
>
> Not sure what that way would be.

Fix switch-to-buffer?

Eg make it call pop-to-buffer-same-window in the non-interactive-case?
Then make a new function
switch-to-buffer-sometimes-fails-and-you-probably-dont-want-this
that does what the old version used to?

Since you say above that "most" calls to switch-to-buffer were wrong,
why not fix the majority by fixing switch-to-buffer, and let the
minority of cases which need to do something different do so, if and
when it turns out to matter?

Re: switch-to-buffer: for interactive use only

[Glenn Morris]

Glenn Morris wrote:

> Fix switch-to-buffer?
>
> Eg make it call pop-to-buffer-same-window in the non-interactive-case?
> Then make a new function
> switch-to-buffer-sometimes-fails-and-you-probably-dont-want-this
> that does what the old version used to?

Or better still, just add an optional MAYBE-FAIL argument to
switch-to-buffer, defaulting to nil, but t in interactive use.
If nil, s-t-b will choose another window if the current one is
unsuitable (eg dedicated or a minibuffer); otherwise it will return an
error. I think that would make the distinction clear.

I mean, say 90% of the current uses of s-t-b are "wrong".
If you fix s-t-b, you've reduced the amount of other code you have to
change by a factor of 9.

On the other hand, if more than say 10% of the current uses are "right",
then you probably should not be saying it should not be used in Lisp
code.

Re: switch-to-buffer: for interactive use only

[Andreas Röhler]

Am 06.07.2011 03:49, schrieb Glenn Morris:
> Stefan Monnier wrote:
>
>> Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
>> being typically a user like myself who uses dedicated windows and/or
>> minibuffer-only frames).
> [...]
>>> Isn't there a better way to handle this than replacing hundreds of
>>> calls with `pop-to-buffer-same-window'?
>>
>> Not sure what that way would be.
>
> Fix switch-to-buffer?
>
> Eg make it call pop-to-buffer-same-window in the non-interactive-case?
> Then make a new function
> switch-to-buffer-sometimes-fails-and-you-probably-dont-want-this
> that does what the old version used to?
>
> Since you say above that "most" calls to switch-to-buffer were wrong,
> why not fix the majority by fixing switch-to-buffer, and let the
> minority of cases which need to do something different do so, if and
> when it turns out to matter?
>
>

Hi,

AFAIU switch-to-buffer is simply not TRT when called from a program.
AFAICT it has the nasty side-effect slowing down execution, introducing 
that kind of bug at least.

So far marking "for interacive use only" looks correct for me.

Cheers,

Andreas

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

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

>> Was it really necessary to mark switch-to-buffer "for interactive use
>> only"? It's a pretty basic command that was used in ~ 800 places in the
>> Emacs 23.3 sources.
>
> Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
> being typically a user like myself who uses dedicated windows and/or
> minibuffer-only frames).

How would you change this?

(defun unbury-buffer ()
  "Switch to the last buffer in the buffer list."
  (interactive)
  (switch-to-buffer (last-buffer)))

Re: switch-to-buffer: for interactive use only

[Štěpán Němec]

Chong Yidong <cyd@stupidchicken.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> Was it really necessary to mark switch-to-buffer "for interactive use
>>> only"? It's a pretty basic command that was used in ~ 800 places in the
>>> Emacs 23.3 sources.
>>
>> Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
>> being typically a user like myself who uses dedicated windows and/or
>> minibuffer-only frames).
>
> How would you change this?
>
> (defun unbury-buffer ()
>   "Switch to the last buffer in the buffer list."
>   (interactive)
>   (switch-to-buffer (last-buffer)))

FWIW, I don't have an opinion on whether marking `switch-to-buffer'
interactive-only makes sense or not, but I don't think the above is a
valid argument either way -- the fact that a function is marked
interactive only (and a compiler warning is produced) does IMO not mean
there are no valid uses from Lisp code -- there are cases where the
interactive behaviour is precisely what you want, and the function above
is one such example. It's similar to using commands like `next-line' or
`beginning-of-buffer' from another command that e.g. functions as a
dispatcher among multiple commands or only slightly modifies the
interactive behaviour (e.g. by fixing one of the arguments, as is the
case with your function).

  Štěpán

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

>>> Was it really necessary to mark switch-to-buffer "for interactive use
>>> only"? It's a pretty basic command that was used in ~ 800 places in the
>>> Emacs 23.3 sources.
>> 
>> Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
>> being typically a user like myself who uses dedicated windows and/or
>> minibuffer-only frames).

> How would you change this?

> (defun unbury-buffer ()
>   "Switch to the last buffer in the buffer list."
>   (interactive)
>   (switch-to-buffer (last-buffer)))

Either using with-no-warnings or using set-window-buffer.


        Stefan

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

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

>> How would you change this?
>
>> (defun unbury-buffer ()
>>   "Switch to the last buffer in the buffer list."
>>   (interactive)
>>   (switch-to-buffer (last-buffer)))
>
> Either using with-no-warnings or using set-window-buffer.

What's wrong with using switch-to-buffer?

If you could elaborate a bit more on what bugs you are referring to when
you say

> Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
> being typically a user like myself who uses dedicated windows and/or
> minibuffer-only frames).

then maybe we could come up with a way to issue the warning more
selectively.  Because AFAICT the usage in unbury-buffer, and probably
many other places in Emacs, is completely correct, and I agree with
Glenn that issuing a zillion warnings for this not satisfactory.

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

>>> How would you change this?
>> 
>>> (defun unbury-buffer ()
>>> "Switch to the last buffer in the buffer list."
>>> (interactive)
>>> (switch-to-buffer (last-buffer)))
>> 
>> Either using with-no-warnings or using set-window-buffer.

> What's wrong with using switch-to-buffer?

> If you could elaborate a bit more on what bugs you are referring to when
> you say

>> Most of those calls were bugs waiting to catch you in Emacs<23 ("you"
>> being typically a user like myself who uses dedicated windows and/or
>> minibuffer-only frames).

> then maybe we could come up with a way to issue the warning more
> selectively.  Because AFAICT the usage in unbury-buffer, and probably
> many other places in Emacs, is completely correct, and I agree with
> Glenn that issuing a zillion warnings for this not satisfactory.

There are two different uses of switch-to-buffer:
- the ones like in unbury-buffer where the main point is that it
  operates on the selected window.
- the ones like in find-file where the main point is that it wants to
  display a given buffer.

In single-frame circumstances, the two cases are identical, so most
authors who use Emacs in a single-frame mode don't even realize that
there's a choice to be made.

Until Emacs-23, switch-to-buffer assumed the main point was to only
affect the selected-window (and hence signal an error if the switch is
not possible).

In Emacs-23, I've changed it to assume that the main point is to display
the given buffer (by delegating the job to pop-to-buffer if necessary).

Recently, I reverted my Emacs-23 change because it introduced bugs
(e.g. in unbury-buffer and bs--cycle-next).


        Stefan


PS: BTW, I think the interactive use of switch-to-buffer is "the second
case" (and should hence call pop-to-buffer-same-window).

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

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

> There are two different uses of switch-to-buffer:
> - the ones like in unbury-buffer where the main point is that it
>   operates on the selected window.
> - the ones like in find-file where the main point is that it wants to
>   display a given buffer.
>
> In single-frame circumstances, the two cases are identical, so most
> authors who use Emacs in a single-frame mode don't even realize that
> there's a choice to be made.
>
> Until Emacs-23, switch-to-buffer assumed the main point was to only
> affect the selected-window (and hence signal an error if the switch is
> not possible).
>
> In Emacs-23, I've changed it to assume that the main point is to
> display the given buffer (by delegating the job to pop-to-buffer if
> necessary).
>
> Recently, I reverted my Emacs-23 change because it introduced bugs
> (e.g. in unbury-buffer and bs--cycle-next).

How bout if switch-to-buffer tries to operate on the selected window,
and calls pop-to-buffer if that is not possible?

Re: switch-to-buffer: for interactive use only

[Juanma Barranquero]

On Fri, Jul 8, 2011 at 01:39, Chong Yidong <cyd@stupidchicken.com> wrote:

> How bout if switch-to-buffer tries to operate on the selected window,
> and calls pop-to-buffer if that is not possible?

Isn't that pop-to-buffer-same-window?

    Juanma

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jul 8, 2011 at 01:39, Chong Yidong <cyd@stupidchicken.com> wrote:
>
>> How bout if switch-to-buffer tries to operate on the selected window,
>> and calls pop-to-buffer if that is not possible?
>
> Isn't that pop-to-buffer-same-window?

Yes, except switch-to-buffer has been around for much longer ;-)

So: how bout getting rid of `pop-to-buffer-same-window' and making
`switch-to-buffer' do what it does.

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 > There are two different uses of switch-to-buffer:
 > - the ones like in unbury-buffer where the main point is that it
 >   operates on the selected window.
 > - the ones like in find-file where the main point is that it wants to
 >   display a given buffer.
 >
 > In single-frame circumstances, the two cases are identical, so most
 > authors who use Emacs in a single-frame mode don't even realize that
 > there's a choice to be made.

They are identical for the single-frame/single-window case.  The main
difference is that `switch-to-buffer' doesn't care whether the selected
window is weakly dedicated.

 > PS: BTW, I think the interactive use of switch-to-buffer is "the second
 > case" (and should hence call pop-to-buffer-same-window).

If this refers to the two cases cited above, then I think that the
interactive use of `switch-to-buffer' is "the first case" and should not
call `pop-to-buffer-same-window'.

martin

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 > How bout if switch-to-buffer tries to operate on the selected window,
 > and calls pop-to-buffer if that is not possible?

That's what it tried to do until Stefan's change.  It's wrong for two
reasons:

- It can use the selected window even if it's weakly dedicated.

- It cannot be customized unless the selected is strongly dedicated.

martin

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 >> How bout if switch-to-buffer tries to operate on the selected window,
 >> and calls pop-to-buffer if that is not possible?
 >
 > Isn't that pop-to-buffer-same-window?

No.  `pop-to-buffer-same-window' doesn't use the selected window if it's
weakly dedicated.  Think of making a window dedicated as a poor man's
way of saying "leave this window alone unless I explicitly want to show
another buffer in it".

martin

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

>> PS: BTW, I think the interactive use of switch-to-buffer is "the second
>> case" (and should hence call pop-to-buffer-same-window).
> If this refers to the two cases cited above, then I think that the
> interactive use of `switch-to-buffer' is "the first case" and should not
> call `pop-to-buffer-same-window'.

At least when called from a minibuffer-only frame, C-x b should pretty
clearly use pop-to-buffer(-same-window) rather than signal an error.

> No.  `pop-to-buffer-same-window' doesn't use the selected window if it's
> weakly dedicated.  Think of making a window dedicated as a poor man's
> way of saying "leave this window alone unless I explicitly want to show
> another buffer in it".

That's a mistake: if the window is fully dedicated, that's right, but if
it's weakly dedicated, pop-to-buffer-same-window should override the
weak dedication, like switch-to-buffer does (otherwise, there would
never be any difference between the two forms of dedication).


        Stefan

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 >> No.  `pop-to-buffer-same-window' doesn't use the selected window if it's
 >> weakly dedicated.  Think of making a window dedicated as a poor man's
 >> way of saying "leave this window alone unless I explicitly want to show
 >> another buffer in it".
 >
 > That's a mistake: if the window is fully dedicated, that's right, but if
 > it's weakly dedicated, pop-to-buffer-same-window should override the
 > weak dedication, like switch-to-buffer does (otherwise, there would
 > never be any difference between the two forms of dedication).

Do you want to change this in the sense that both `switch-to-buffer' and
`pop-to-buffer-same-window' should reuse a weakly dedicated window?  In
that case I'd obviously agree with Chong that there's no real difference
between the two.

So we should make `switch-to-buffer' do what it has always done (just
that now it's more fully customizable).  I'm not sure though whether you
would want to make `display-buffer' reuse weakly dedicated windows too?
What would weak dedication be good for then?

martin

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

>>> No.  `pop-to-buffer-same-window' doesn't use the selected window if it's
>>> weakly dedicated.  Think of making a window dedicated as a poor man's
>>> way of saying "leave this window alone unless I explicitly want to show
>>> another buffer in it".
>> That's a mistake: if the window is fully dedicated, that's right, but if
>> it's weakly dedicated, pop-to-buffer-same-window should override the
>> weak dedication, like switch-to-buffer does (otherwise, there would
>> never be any difference between the two forms of dedication).
> Do you want to change this in the sense that both `switch-to-buffer' and
> `pop-to-buffer-same-window' should reuse a weakly dedicated window?

Yes.

> In that case I'd obviously agree with Chong that there's no real
> difference between the two.

> So we should make `switch-to-buffer' do what it has always done (just
> that now it's more fully customizable).

I'm not sure what "what it has always done" refers to.  What it used to
do in Emacs-22 (and does again right now) or what it used to do in Emacs-23?

> I'm not sure though whether you
> would want to make `display-buffer' reuse weakly dedicated windows too?

No, indeed, not display-buffer.


        Stefan

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 >> So we should make `switch-to-buffer' do what it has always done (just
 >> that now it's more fully customizable).
 >
 > I'm not sure what "what it has always done" refers to.  What it used to
 > do in Emacs-22 (and does again right now) or what it used to do in Emacs-23?

I meant we shouldn't distinguish between a `switch-to-buffer' function
and a `pop-to-buffer-same-window' function since both would end up doing
essentially the same thing `switch-to-buffer' always did.  Or is the
main motivation that `pop-to-buffer-same-window' has a built-in fallback
for strongly dedicated windows?

 >> I'm not sure though whether you
 >> would want to make `display-buffer' reuse weakly dedicated windows too?
 >
 > No, indeed, not display-buffer.

Then tell my what you expect a function like `pop-to-buffer-same-window'
do differently from `switch-to-buffer'.  In any case we have to give it
a different name since the `pop-to-buffer' family functions never reuse
dedicated windows.

martin

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

>>> I'm not sure though whether you
>>> would want to make `display-buffer' reuse weakly dedicated windows too?
>> No, indeed, not display-buffer.
> Then tell my what you expect a function like `pop-to-buffer-same-window'
> do differently from `switch-to-buffer'.

One of the two needs to display the buffer, "no matter what", whereas
the other needs to only affect the selected window.


        Stefan

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

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

>> Then tell my what you expect a function like `pop-to-buffer-same-window'
>> do differently from `switch-to-buffer'.
>
> One of the two needs to display the buffer, "no matter what", whereas
> the other needs to only affect the selected window.

Why does `switch-to-buffer' need to only affect the selected window?
What's wrong with using a different window, instead of signaling a
error, if the selected window can't be used?

Re: switch-to-buffer: for interactive use only

[Juanma Barranquero]

On Fri, Jul 8, 2011 at 22:12, Chong Yidong <cyd@stupidchicken.com> wrote:

> Why does `switch-to-buffer' need to only affect the selected window?
> What's wrong with using a different window, instead of signaling a
> error, if the selected window can't be used?

That would resurrect the bug recently fixed in bs-cycle-next where it
opened another window when the selected one was strongly dedicated. It
is called "cycle", not "bring-me": either it can cycle a new buffer
into the window, or it should say that it cannot. That's what it does
now, and that's the right thing to do.

For some operations on a buffer with a strongly dedicated window, it
makes sense to pop up another window; for some others, it does not.
Conflating both is never going to be a good answer. Well, strictly
speaking, we can do that and use `display-buffer-alist' to allow the
user to override it; but bs-cycle-next, and operations of that kind,
should do the right thing out of the box.

    Juanma

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> That would resurrect the bug recently fixed in bs-cycle-next where it
> opened another window when the selected one was strongly dedicated. It
> is called "cycle", not "bring-me": either it can cycle a new buffer
> into the window, or it should say that it cannot. That's what it does
> now, and that's the right thing to do.
>
> For some operations on a buffer with a strongly dedicated window, it
> makes sense to pop up another window; for some others, it does not.
> Conflating both is never going to be a good answer. Well, strictly
> speaking, we can do that and use `display-buffer-alist' to allow the
> user to override it; but bs-cycle-next, and operations of that kind,
> should do the right thing out of the box.

It seems to me that such cases are very much in the minority---AFAICT,
the vast majority of uses of switch-to-buffer in the Emacs sources
simply have the intention "show BUFFER, but try not to make a new window
to do it".

So, if creating a new window is the wrong thing for bs-cycle-next, it
should be bs-cycle-next that changes---e.g. by changing from
switch-to-buffer to set-window-buffer---not everything else in Emacs.

Re: switch-to-buffer: for interactive use only

[Juanma Barranquero]

On Fri, Jul 8, 2011 at 22:50, Chong Yidong <cyd@stupidchicken.com> wrote:

> It seems to me that such cases are very much in the minority---AFAICT,
> the vast majority of uses of switch-to-buffer in the Emacs sources
> simply have the intention "show BUFFER, but try not to make a new window
> to do it".
>
> So, if creating a new window is the wrong thing for bs-cycle-next, it
> should be bs-cycle-next that changes---e.g. by changing from
> switch-to-buffer to set-window-buffer---not everything else in Emacs.

I don't remember saying that it is the rest of Emacs which must be
changed; only that there are two different use cases, and we must
cater to both.

    Juanma

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

>> So, if creating a new window is the wrong thing for bs-cycle-next, it
>> should be bs-cycle-next that changes---e.g. by changing from
>> switch-to-buffer to set-window-buffer---not everything else in Emacs.
>
> I don't remember saying that it is the rest of Emacs which must be
> changed; only that there are two different use cases, and we must
> cater to both.

Fair enough.  So, I propose the following:

- Make switch-to-buffer basically do
  (pop-to-buffer buffer-or-name 'same-window norecord label)

- Make pop-to-buffer-same-window an alias for switch-to-buffer.
  (This means to add an optional LABEL arg to switch-to-buffer, for
  consistency with pop-to-buffer-same-window.)

- Remove the "interactive use only" flag from switch-to-buffer.

- For those places that intend the "act on the selected window"
  behavior---which is the minority---change the code to call
  (set-window-buffer (selected-window) buffer), instead of
  switch-to-buffer.

How's that?

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

> Fair enough.  So, I propose the following:
> - Make switch-to-buffer basically do
>   (pop-to-buffer buffer-or-name 'same-window norecord label)

OK.  So mostly revert to Emacs-23 behavior.

> - Make pop-to-buffer-same-window an alias for switch-to-buffer.
>   (This means to add an optional LABEL arg to switch-to-buffer, for
>   consistency with pop-to-buffer-same-window.)

We may as well get rid of pop-to-buffer-same-window (those who want to
provide a LABEL can use pop-to-buffer instead).

> - For those places that intend the "act on the selected window"
>   behavior---which is the minority---change the code to call
>   (set-window-buffer (selected-window) buffer), instead of
>   switch-to-buffer.

Note that (set-window-buffer (selected-window) buffer) isn't quite good
enough, since set-window-buffer will be happy to change the buffer of
a mini-window, whereas callers of switch-to-buffer that want to operate
on the selected window should signal an error in that case.
I think adding a `selected-window-only' argument to switch-to-buffer is
a better solution so callers don't need to worry about such details of
set-window-buffer.


        Stefan

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 > Fair enough.  So, I propose the following:
 >
 > - Make switch-to-buffer basically do
 >   (pop-to-buffer buffer-or-name 'same-window norecord label)

Stefan wants the "basically" used function reuse weakly dedicated
windows so you need a reuse-dedicated non-t specifier here.

 > - Make pop-to-buffer-same-window an alias for switch-to-buffer.
 >   (This means to add an optional LABEL arg to switch-to-buffer, for
 >   consistency with pop-to-buffer-same-window.)

Only if you do not change the code of `pop-to-buffer-same-window'.  I'll
need that elsewhere as is.

 > - Remove the "interactive use only" flag from switch-to-buffer.

Good.

 > - For those places that intend the "act on the selected window"
 >   behavior---which is the minority---change the code to call
 >   (set-window-buffer (selected-window) buffer), instead of
 >   switch-to-buffer.

Only if we make minibuffer windows dedicated ;-)

martin

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 > We may as well get rid of pop-to-buffer-same-window (those who want to
 > provide a LABEL can use pop-to-buffer instead).

I wouldn't object.  The functionality is obviously needed to get rid of
all those

(add-to-list 'same-window-buffer-names (purecopy "*Python*"))

;;;###autoload (add-hook 'same-window-buffer-names (purecopy "*scheme*"))

but if there are any doubts about too many pop-to-buffer-... or
display-buffer-... definitions please let me know.

 >> - For those places that intend the "act on the selected window"
 >>   behavior---which is the minority---change the code to call
 >>   (set-window-buffer (selected-window) buffer), instead of
 >>   switch-to-buffer.
 >
 > Note that (set-window-buffer (selected-window) buffer) isn't quite good
 > enough, since set-window-buffer will be happy to change the buffer of
 > a mini-window, whereas callers of switch-to-buffer that want to operate
 > on the selected window should signal an error in that case.
 > I think adding a `selected-window-only' argument to switch-to-buffer is
 > a better solution so callers don't need to worry about such details of
 > set-window-buffer.

What precisely would the semantics of this argument be?

martin

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

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

>> Fair enough.  So, I propose the following:
>> - Make switch-to-buffer basically do
>>   (pop-to-buffer buffer-or-name 'same-window norecord label)
>
> OK.  So mostly revert to Emacs-23 behavior.
>
> Note that (set-window-buffer (selected-window) buffer) isn't quite
> good enough, since set-window-buffer will be happy to change the
> buffer of a mini-window, whereas callers of switch-to-buffer that want
> to operate on the selected window should signal an error in that case.
> I think adding a `selected-window-only' argument to switch-to-buffer
> is a better solution so callers don't need to worry about such details
> of set-window-buffer.

How's this patch?

*** lisp/window.el	2011-07-09 12:32:38 +0000
--- lisp/window.el	2011-07-09 19:21:36 +0000
***************
*** 5925,5931 ****
  	    buffer))
      (other-buffer)))
  
! (defun switch-to-buffer (buffer-or-name &optional norecord)
    "Switch to buffer BUFFER-OR-NAME in the selected window.
  If called interactively, prompt for the buffer name using the
  minibuffer.  The variable `confirm-nonexistent-file-or-buffer'
--- 5925,5931 ----
  	    buffer))
      (other-buffer)))
  
! (defun switch-to-buffer (buffer-or-name &optional norecord force-same-window)
    "Switch to buffer BUFFER-OR-NAME in the selected window.
  If called interactively, prompt for the buffer name using the
  minibuffer.  The variable `confirm-nonexistent-file-or-buffer'
***************
*** 5941,5965 ****
  Optional argument NORECORD non-nil means do not put the buffer
  specified by BUFFER-OR-NAME at the front of the buffer list and
  do not make the window displaying it the most recently selected
! one.  Return the buffer switched to.
  
! This function is intended for interactive use only.  Lisp
! functions should call `pop-to-buffer-same-window' instead."
    (interactive
     (list (read-buffer-to-switch "Switch to buffer: ")))
    (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)))
!     (cond
!      ;; Don't call set-window-buffer if it's not needed since it
!      ;; might signal an error (e.g. if the window is dedicated).
!      ((eq buffer (window-buffer)) nil)
!      ((window-minibuffer-p)
!       (error "Cannot switch buffers in minibuffer window"))
!      ((eq (window-dedicated-p) t)
!       (error "Cannot switch buffers in a dedicated window"))
!      (t (set-window-buffer nil buffer)))
!     (unless norecord
!       (select-window (selected-window)))
!     (set-buffer buffer)))
  
  (defun switch-to-buffer-same-frame (buffer-or-name &optional norecord)
    "Switch to buffer BUFFER-OR-NAME in a window on the selected frame.
--- 5941,5967 ----
  Optional argument NORECORD non-nil means do not put the buffer
  specified by BUFFER-OR-NAME at the front of the buffer list and
  do not make the window displaying it the most recently selected
! one.
  
! If the selected window is weakly dedicated, switch to
! BUFFER-OR-NAME anyway (see `set-window-dedicated-p').  If the
! selected window is strongly dedicated, display BUFFER-OR-NAME in
! another window if FORCE-SAME-WINDOW is nil, and signal an error
! if FORCE-SAME-WINDOW if non-nil.
! 
! Return the buffer switched to."
    (interactive
     (list (read-buffer-to-switch "Switch to buffer: ")))
    (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)))
!     (when force-same-window
!       (cond
!        ((window-minibuffer-p)
!   	(error "Cannot switch buffers in minibuffer window"))
!        ((eq (window-dedicated-p) t)
!   	(error "Cannot switch buffers in a dedicated window"))))
!     (pop-to-buffer buffer-or-name
! 		   '(same-window (reuse-window-dedicated . weak))
! 		   norecord nil)))
  
  (defun switch-to-buffer-same-frame (buffer-or-name &optional norecord)
    "Switch to buffer BUFFER-OR-NAME in a window on the selected frame.

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 > How's this patch?

IIUC in interactive use `switch-to-buffer' wants `force-same-window'
non-nil.  How do you address that here?

 >     (interactive
 >      (list (read-buffer-to-switch "Switch to buffer: ")))
 >     (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)))
 > !     (when force-same-window
 > !       (cond
 > !        ((window-minibuffer-p)
 > !   	(error "Cannot switch buffers in minibuffer window"))
 > !        ((eq (window-dedicated-p) t)
 > !   	(error "Cannot switch buffers in a dedicated window"))))
 > !     (pop-to-buffer buffer-or-name
 > ! 		   '(same-window (reuse-window-dedicated . weak))
 > ! 		   norecord nil)))

martin

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> How's this patch?
>
> IIUC in interactive use `switch-to-buffer' wants `force-same-window'
> non-nil.

Do we?  OK---though I'm not sure what the rationale is.

> How do you address that here?

Just change the interactive spec to

  (interactive
   (list (read-buffer-to-switch "Switch to buffer: ") nil t))

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 >> IIUC in interactive use `switch-to-buffer' wants `force-same-window'
 >> non-nil.
 >
 > Do we?  OK---though I'm not sure what the rationale is.

I suppose because we don't want to change the behavior of C-x b.

martin

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

>> Note that (set-window-buffer (selected-window) buffer) isn't quite good
>> enough, since set-window-buffer will be happy to change the buffer of
>> a mini-window, whereas callers of switch-to-buffer that want to operate
>> on the selected window should signal an error in that case.
>> I think adding a `selected-window-only' argument to switch-to-buffer is
>> a better solution so callers don't need to worry about such details of
>> set-window-buffer.

> What precisely would the semantics of this argument be?

That if the buffer can't be shown in the selected window, then it should
signal an error rather than try to use some other window.


        Stefan

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

> ! If the selected window is weakly dedicated, switch to
> ! BUFFER-OR-NAME anyway (see `set-window-dedicated-p').  If the
> ! selected window is strongly dedicated, display BUFFER-OR-NAME in
> ! another window if FORCE-SAME-WINDOW is nil, and signal an error
> ! if FORCE-SAME-WINDOW if non-nil.

I don't think it's necessary to talk so much about dedicated windows.
And FORCE-SAME-WINDOW should simply means that it will signal an error
if it can't use the selected window.

> ! Return the buffer switched to."
>     (interactive
>      (list (read-buffer-to-switch "Switch to buffer: ")))
>     (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)))
> !     (when force-same-window
> !       (cond
> !        ((window-minibuffer-p)
> !   	(error "Cannot switch buffers in minibuffer window"))
> !        ((eq (window-dedicated-p) t)
> !   	(error "Cannot switch buffers in a dedicated window"))))
> !     (pop-to-buffer buffer-or-name
> ! 		   '(same-window (reuse-window-dedicated . weak))
> ! 		   norecord nil)))
  
AFAIU, this can still use another window when force-same-window is
non-nil.


        Stefan

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 >> What precisely would the semantics of this argument be?
 >
 > That if the buffer can't be shown in the selected window, then it should
 > signal an error rather than try to use some other window.

Sorry.  What would the semantics of "if the buffer can't be shown in the
selected window" be?

Is "If that argument is non-nil and the selected window is either a
minibuffer window or strongly dedicated to its buffer, signal an error."
the intended usage?

martin

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

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

>> ! Return the buffer switched to."
>>     (interactive
>>      (list (read-buffer-to-switch "Switch to buffer: ")))
>>     (let ((buffer (window-normalize-buffer-to-switch-to buffer-or-name)))
>> !     (when force-same-window
>> !       (cond
>> !        ((window-minibuffer-p)
>> !   	(error "Cannot switch buffers in minibuffer window"))
>> !        ((eq (window-dedicated-p) t)
>> !   	(error "Cannot switch buffers in a dedicated window"))))
>> !     (pop-to-buffer buffer-or-name
>> ! 		   '(same-window (reuse-window-dedicated . weak))
>> ! 		   norecord nil)))
>
> AFAIU, this can still use another window when force-same-window is
> non-nil.

Not unless there is another special case apart from minibuffer and
strongly dedicated windows.

Re: switch-to-buffer: for interactive use only

[Stefan Monnier]

>>> !     (pop-to-buffer buffer-or-name
>>> ! 		   '(same-window (reuse-window-dedicated . weak))
>>> ! 		   norecord nil)))
>> AFAIU, this can still use another window when force-same-window is
>> non-nil.
> Not unless there is another special case apart from minibuffer and
> strongly dedicated windows.

IIUC There can be tons of special cases introduced by
display-buffer-alist.


        Stefan

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 > IIUC There can be tons of special cases introduced by
 > display-buffer-alist.

Add a big general one introduced by `display-buffer-function'.

martin

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> IIUC There can be tons of special cases introduced by
>> display-buffer-alist.
>
> Add a big general one introduced by `display-buffer-function'.

I'm not so concerned about display-buffer-function; it's up to the users
of that to DTRT.  As for display-buffer-alist, we can bind it to nil
within switch-to-buffer.

Re: switch-to-buffer: for interactive use only

[martin rudalics]

 > I'm not so concerned about display-buffer-function; it's up to the users
 > of that to DTRT.  As for display-buffer-alist, we can bind it to nil
 > within switch-to-buffer.

I think that we want two types of `switch-to-buffer' functions:

(1) The one where using any window but the selected doesn't make sense.
     This seems the case for C-x b and maybe a few other cases.  We could
     use a `set-window-buffer' based function here and error out if the
     selected window is strongly dedicated or the minibuffer window.
     Call this function `switch-to-buffer-same-window' and bind C-x b to
     it.  This function would be marked as not callable from Elisp.

(2) A function that pops to a buffer, preferably in the selected window.
     This is the case for almost all other calls of `switch-to-buffer'.
     For this we could rewrite `switch-to-buffer' to call `pop-to-buffer'
     with the 'same-window argument and, if Stefan insists, make it reuse
     the same window even if it's weakly dedicated.  This function would
     be callable from Elisp.

Anything wrong with this approach?

martin

Re: switch-to-buffer: for interactive use only

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

> I think that we want two types of `switch-to-buffer' functions:
>
> (1) The one where using any window but the selected doesn't make sense.
>     This seems the case for C-x b and maybe a few other cases.  We could
>     use a `set-window-buffer' based function here and error out if the
>     selected window is strongly dedicated or the minibuffer window.
>     Call this function `switch-to-buffer-same-window' and bind C-x b to
>     it.  This function would be marked as not callable from Elisp.
>
> (2) A function that pops to a buffer, preferably in the selected window.
>     This is the case for almost all other calls of `switch-to-buffer'.
>     For this we could rewrite `switch-to-buffer' to call `pop-to-buffer'
>     with the 'same-window argument and, if Stefan insists, make it reuse
>     the same window even if it's weakly dedicated.  This function would
>     be callable from Elisp.

C-x b is usually called because the user wants to go to another buffer,
so if the selected window absolutely can't be used then it's better for
the command should intelligently handle it by using another window.

As for non-interactive usage, that's addressed by the FORCE-SAME-WINDOW
argument.  Those callers that want to force selecting the same window
specific can use this arg, so we don't need a different function.

After discussing with Stefan off-list, I've committed the change to
switch-to-buffer that adds the FORCE-SAME-WINDOW argument.  I'll get to
changing the callers shortly.

Re: switch-to-buffer: for interactive use only

[grischka]

> I think that we want two types of `switch-to-buffer' functions:
> 
> (1) [...] C-x b [...] set-window-buffer' based [...] not callable
>     from Elisp.
> 
> (2) [...] callable from Elisp.
> 
> Anything wrong with this approach?

Yes.  I've observed this elsewhere earlier. It means that emacs to
support its native UI, uses tricks that aren't available for the
mere mortals.  However if there is anything that actually flies
then it's the built-in always existing UI's such as completion or
help.

Only naturally that people will want their thing work equally well,
sooner or later learn the necessary tricks and then you are back in
the situation where you have zero control for consistency because
your freshly designed interface is consequently bypassed by, which
is only worse, those who actually care for good UI.

--- grischka

> 
> martin