* switch-to-buffer: for interactive use only
@ 2011-07-05 21:40 Glenn Morris
2011-07-05 23:23 ` Juanma Barranquero
2011-07-06 1:18 ` Stefan Monnier
0 siblings, 2 replies; 47+ messages in thread
From: Glenn Morris @ 2011-07-05 21:40 UTC (permalink / raw
To: emacs-devel
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'?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-05 21:40 switch-to-buffer: for interactive use only Glenn Morris
@ 2011-07-05 23:23 ` Juanma Barranquero
2011-07-05 23:32 ` Glenn Morris
2011-07-06 1:18 ` Stefan Monnier
1 sibling, 1 reply; 47+ messages in thread
From: Juanma Barranquero @ 2011-07-05 23:23 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-05 23:23 ` Juanma Barranquero
@ 2011-07-05 23:32 ` Glenn Morris
2011-07-05 23:34 ` Juanma Barranquero
2011-07-05 23:41 ` Juanma Barranquero
0 siblings, 2 replies; 47+ messages in thread
From: Glenn Morris @ 2011-07-05 23:32 UTC (permalink / raw
To: Juanma Barranquero; +Cc: emacs-devel
>> 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.)
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-05 23:32 ` Glenn Morris
@ 2011-07-05 23:34 ` Juanma Barranquero
2011-07-05 23:41 ` Juanma Barranquero
1 sibling, 0 replies; 47+ messages in thread
From: Juanma Barranquero @ 2011-07-05 23:34 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-05 23:32 ` Glenn Morris
2011-07-05 23:34 ` Juanma Barranquero
@ 2011-07-05 23:41 ` Juanma Barranquero
1 sibling, 0 replies; 47+ messages in thread
From: Juanma Barranquero @ 2011-07-05 23:41 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-05 21:40 switch-to-buffer: for interactive use only Glenn Morris
2011-07-05 23:23 ` Juanma Barranquero
@ 2011-07-06 1:18 ` Stefan Monnier
2011-07-06 1:49 ` Glenn Morris
2011-07-06 21:10 ` Chong Yidong
1 sibling, 2 replies; 47+ messages in thread
From: Stefan Monnier @ 2011-07-06 1:18 UTC (permalink / raw
To: Glenn Morris; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-06 1:18 ` Stefan Monnier
@ 2011-07-06 1:49 ` Glenn Morris
2011-07-06 2:27 ` Glenn Morris
2011-07-06 5:55 ` Andreas Röhler
2011-07-06 21:10 ` Chong Yidong
1 sibling, 2 replies; 47+ messages in thread
From: Glenn Morris @ 2011-07-06 1:49 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-06 1:49 ` Glenn Morris
@ 2011-07-06 2:27 ` Glenn Morris
2011-07-06 5:55 ` Andreas Röhler
1 sibling, 0 replies; 47+ messages in thread
From: Glenn Morris @ 2011-07-06 2:27 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-06 1:49 ` Glenn Morris
2011-07-06 2:27 ` Glenn Morris
@ 2011-07-06 5:55 ` Andreas Röhler
1 sibling, 0 replies; 47+ messages in thread
From: Andreas Röhler @ 2011-07-06 5:55 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-06 1:18 ` Stefan Monnier
2011-07-06 1:49 ` Glenn Morris
@ 2011-07-06 21:10 ` Chong Yidong
2011-07-07 9:19 ` Štěpán Němec
2011-07-07 19:52 ` Stefan Monnier
1 sibling, 2 replies; 47+ messages in thread
From: Chong Yidong @ 2011-07-06 21:10 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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)))
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-06 21:10 ` Chong Yidong
@ 2011-07-07 9:19 ` Štěpán Němec
2011-07-07 19:52 ` Stefan Monnier
1 sibling, 0 replies; 47+ messages in thread
From: Štěpán Němec @ 2011-07-07 9:19 UTC (permalink / raw
To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-06 21:10 ` Chong Yidong
2011-07-07 9:19 ` Štěpán Němec
@ 2011-07-07 19:52 ` Stefan Monnier
2011-07-07 20:50 ` Chong Yidong
1 sibling, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-07-07 19:52 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-07 19:52 ` Stefan Monnier
@ 2011-07-07 20:50 ` Chong Yidong
2011-07-07 21:11 ` Stefan Monnier
0 siblings, 1 reply; 47+ messages in thread
From: Chong Yidong @ 2011-07-07 20:50 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-07 20:50 ` Chong Yidong
@ 2011-07-07 21:11 ` Stefan Monnier
2011-07-07 23:39 ` Chong Yidong
2011-07-08 6:43 ` martin rudalics
0 siblings, 2 replies; 47+ messages in thread
From: Stefan Monnier @ 2011-07-07 21:11 UTC (permalink / raw
To: Chong Yidong; +Cc: emacs-devel
>>> 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).
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-07 21:11 ` Stefan Monnier
@ 2011-07-07 23:39 ` Chong Yidong
2011-07-08 0:09 ` Juanma Barranquero
2011-07-08 6:44 ` martin rudalics
2011-07-08 6:43 ` martin rudalics
1 sibling, 2 replies; 47+ messages in thread
From: Chong Yidong @ 2011-07-07 23:39 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-07 23:39 ` Chong Yidong
@ 2011-07-08 0:09 ` Juanma Barranquero
2011-07-08 1:12 ` Chong Yidong
2011-07-08 6:44 ` martin rudalics
2011-07-08 6:44 ` martin rudalics
1 sibling, 2 replies; 47+ messages in thread
From: Juanma Barranquero @ 2011-07-08 0:09 UTC (permalink / raw
To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 0:09 ` Juanma Barranquero
@ 2011-07-08 1:12 ` Chong Yidong
2011-07-08 6:44 ` martin rudalics
1 sibling, 0 replies; 47+ messages in thread
From: Chong Yidong @ 2011-07-08 1:12 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 0:09 ` Juanma Barranquero
2011-07-08 1:12 ` Chong Yidong
@ 2011-07-08 6:44 ` martin rudalics
1 sibling, 0 replies; 47+ messages in thread
From: martin rudalics @ 2011-07-08 6:44 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Chong Yidong, Stefan Monnier, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-07 23:39 ` Chong Yidong
2011-07-08 0:09 ` Juanma Barranquero
@ 2011-07-08 6:44 ` martin rudalics
1 sibling, 0 replies; 47+ messages in thread
From: martin rudalics @ 2011-07-08 6:44 UTC (permalink / raw
To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-07 21:11 ` Stefan Monnier
2011-07-07 23:39 ` Chong Yidong
@ 2011-07-08 6:43 ` martin rudalics
2011-07-08 12:57 ` Stefan Monnier
1 sibling, 1 reply; 47+ messages in thread
From: martin rudalics @ 2011-07-08 6:43 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 6:43 ` martin rudalics
@ 2011-07-08 12:57 ` Stefan Monnier
2011-07-08 14:03 ` martin rudalics
0 siblings, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-07-08 12:57 UTC (permalink / raw
To: martin rudalics; +Cc: Chong Yidong, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 12:57 ` Stefan Monnier
@ 2011-07-08 14:03 ` martin rudalics
2011-07-08 15:46 ` Stefan Monnier
0 siblings, 1 reply; 47+ messages in thread
From: martin rudalics @ 2011-07-08 14:03 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 14:03 ` martin rudalics
@ 2011-07-08 15:46 ` Stefan Monnier
2011-07-08 16:45 ` martin rudalics
0 siblings, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-07-08 15:46 UTC (permalink / raw
To: martin rudalics; +Cc: Chong Yidong, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 15:46 ` Stefan Monnier
@ 2011-07-08 16:45 ` martin rudalics
2011-07-08 18:46 ` Stefan Monnier
0 siblings, 1 reply; 47+ messages in thread
From: martin rudalics @ 2011-07-08 16:45 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 16:45 ` martin rudalics
@ 2011-07-08 18:46 ` Stefan Monnier
2011-07-08 20:12 ` Chong Yidong
0 siblings, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-07-08 18:46 UTC (permalink / raw
To: martin rudalics; +Cc: Chong Yidong, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 18:46 ` Stefan Monnier
@ 2011-07-08 20:12 ` Chong Yidong
2011-07-08 20:34 ` Juanma Barranquero
0 siblings, 1 reply; 47+ messages in thread
From: Chong Yidong @ 2011-07-08 20:12 UTC (permalink / raw
To: Stefan Monnier; +Cc: martin rudalics, emacs-devel
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 20:12 ` Chong Yidong
@ 2011-07-08 20:34 ` Juanma Barranquero
2011-07-08 20:50 ` Chong Yidong
0 siblings, 1 reply; 47+ messages in thread
From: Juanma Barranquero @ 2011-07-08 20:34 UTC (permalink / raw
To: Chong Yidong; +Cc: martin rudalics, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 20:34 ` Juanma Barranquero
@ 2011-07-08 20:50 ` Chong Yidong
2011-07-08 23:16 ` Juanma Barranquero
0 siblings, 1 reply; 47+ messages in thread
From: Chong Yidong @ 2011-07-08 20:50 UTC (permalink / raw
To: Juanma Barranquero; +Cc: martin rudalics, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 20:50 ` Chong Yidong
@ 2011-07-08 23:16 ` Juanma Barranquero
2011-07-09 2:35 ` Chong Yidong
0 siblings, 1 reply; 47+ messages in thread
From: Juanma Barranquero @ 2011-07-08 23:16 UTC (permalink / raw
To: Chong Yidong; +Cc: martin rudalics, Stefan Monnier, emacs-devel
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-08 23:16 ` Juanma Barranquero
@ 2011-07-09 2:35 ` Chong Yidong
2011-07-09 3:09 ` Stefan Monnier
2011-07-09 8:45 ` martin rudalics
0 siblings, 2 replies; 47+ messages in thread
From: Chong Yidong @ 2011-07-09 2:35 UTC (permalink / raw
To: Juanma Barranquero; +Cc: martin rudalics, Stefan Monnier, emacs-devel
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?
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-09 2:35 ` Chong Yidong
@ 2011-07-09 3:09 ` Stefan Monnier
2011-07-09 8:45 ` martin rudalics
2011-07-09 19:25 ` Chong Yidong
2011-07-09 8:45 ` martin rudalics
1 sibling, 2 replies; 47+ messages in thread
From: Stefan Monnier @ 2011-07-09 3:09 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, emacs-devel, 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)
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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-09 3:09 ` Stefan Monnier
@ 2011-07-09 8:45 ` martin rudalics
2011-07-11 3:41 ` Stefan Monnier
2011-07-09 19:25 ` Chong Yidong
1 sibling, 1 reply; 47+ messages in thread
From: martin rudalics @ 2011-07-09 8:45 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, Chong Yidong, emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-09 8:45 ` martin rudalics
@ 2011-07-11 3:41 ` Stefan Monnier
2011-07-11 9:43 ` martin rudalics
0 siblings, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-07-11 3:41 UTC (permalink / raw
To: martin rudalics; +Cc: Juanma Barranquero, Chong Yidong, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-11 3:41 ` Stefan Monnier
@ 2011-07-11 9:43 ` martin rudalics
0 siblings, 0 replies; 47+ messages in thread
From: martin rudalics @ 2011-07-11 9:43 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, Chong Yidong, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-09 3:09 ` Stefan Monnier
2011-07-09 8:45 ` martin rudalics
@ 2011-07-09 19:25 ` Chong Yidong
2011-07-10 9:00 ` martin rudalics
2011-07-11 3:45 ` Stefan Monnier
1 sibling, 2 replies; 47+ messages in thread
From: Chong Yidong @ 2011-07-09 19:25 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel, martin rudalics
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-09 19:25 ` Chong Yidong
@ 2011-07-10 9:00 ` martin rudalics
2011-07-10 13:09 ` Chong Yidong
2011-07-11 3:45 ` Stefan Monnier
1 sibling, 1 reply; 47+ messages in thread
From: martin rudalics @ 2011-07-10 9:00 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, Stefan Monnier, emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-09 19:25 ` Chong Yidong
2011-07-10 9:00 ` martin rudalics
@ 2011-07-11 3:45 ` Stefan Monnier
2011-07-11 14:56 ` Chong Yidong
1 sibling, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-07-11 3:45 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, emacs-devel, martin rudalics
> ! 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-11 3:45 ` Stefan Monnier
@ 2011-07-11 14:56 ` Chong Yidong
2011-07-12 4:25 ` Stefan Monnier
0 siblings, 1 reply; 47+ messages in thread
From: Chong Yidong @ 2011-07-11 14:56 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel, martin rudalics
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-11 14:56 ` Chong Yidong
@ 2011-07-12 4:25 ` Stefan Monnier
2011-07-12 8:36 ` martin rudalics
0 siblings, 1 reply; 47+ messages in thread
From: Stefan Monnier @ 2011-07-12 4:25 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, emacs-devel, martin rudalics
>>> ! (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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-12 4:25 ` Stefan Monnier
@ 2011-07-12 8:36 ` martin rudalics
2011-07-13 15:42 ` Chong Yidong
0 siblings, 1 reply; 47+ messages in thread
From: martin rudalics @ 2011-07-12 8:36 UTC (permalink / raw
To: Stefan Monnier; +Cc: Juanma Barranquero, Chong Yidong, emacs-devel
> IIUC There can be tons of special cases introduced by
> display-buffer-alist.
Add a big general one introduced by `display-buffer-function'.
martin
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-12 8:36 ` martin rudalics
@ 2011-07-13 15:42 ` Chong Yidong
2011-07-13 17:18 ` martin rudalics
0 siblings, 1 reply; 47+ messages in thread
From: Chong Yidong @ 2011-07-13 15:42 UTC (permalink / raw
To: martin rudalics; +Cc: Juanma Barranquero, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-13 15:42 ` Chong Yidong
@ 2011-07-13 17:18 ` martin rudalics
2011-07-13 21:53 ` Chong Yidong
0 siblings, 1 reply; 47+ messages in thread
From: martin rudalics @ 2011-07-13 17:18 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, Stefan Monnier, emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-13 17:18 ` martin rudalics
@ 2011-07-13 21:53 ` Chong Yidong
0 siblings, 0 replies; 47+ messages in thread
From: Chong Yidong @ 2011-07-13 21:53 UTC (permalink / raw
To: martin rudalics; +Cc: Juanma Barranquero, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
2011-07-09 2:35 ` Chong Yidong
2011-07-09 3:09 ` Stefan Monnier
@ 2011-07-09 8:45 ` martin rudalics
1 sibling, 0 replies; 47+ messages in thread
From: martin rudalics @ 2011-07-09 8:45 UTC (permalink / raw
To: Chong Yidong; +Cc: Juanma Barranquero, Stefan Monnier, emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: switch-to-buffer: for interactive use only
@ 2011-07-13 22:13 grischka
0 siblings, 0 replies; 47+ messages in thread
From: grischka @ 2011-07-13 22:13 UTC (permalink / raw
To: rudalics; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2011-07-13 22:13 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-05 21:40 switch-to-buffer: for interactive use only Glenn Morris
2011-07-05 23:23 ` Juanma Barranquero
2011-07-05 23:32 ` Glenn Morris
2011-07-05 23:34 ` Juanma Barranquero
2011-07-05 23:41 ` Juanma Barranquero
2011-07-06 1:18 ` Stefan Monnier
2011-07-06 1:49 ` Glenn Morris
2011-07-06 2:27 ` Glenn Morris
2011-07-06 5:55 ` Andreas Röhler
2011-07-06 21:10 ` Chong Yidong
2011-07-07 9:19 ` Štěpán Němec
2011-07-07 19:52 ` Stefan Monnier
2011-07-07 20:50 ` Chong Yidong
2011-07-07 21:11 ` Stefan Monnier
2011-07-07 23:39 ` Chong Yidong
2011-07-08 0:09 ` Juanma Barranquero
2011-07-08 1:12 ` Chong Yidong
2011-07-08 6:44 ` martin rudalics
2011-07-08 6:44 ` martin rudalics
2011-07-08 6:43 ` martin rudalics
2011-07-08 12:57 ` Stefan Monnier
2011-07-08 14:03 ` martin rudalics
2011-07-08 15:46 ` Stefan Monnier
2011-07-08 16:45 ` martin rudalics
2011-07-08 18:46 ` Stefan Monnier
2011-07-08 20:12 ` Chong Yidong
2011-07-08 20:34 ` Juanma Barranquero
2011-07-08 20:50 ` Chong Yidong
2011-07-08 23:16 ` Juanma Barranquero
2011-07-09 2:35 ` Chong Yidong
2011-07-09 3:09 ` Stefan Monnier
2011-07-09 8:45 ` martin rudalics
2011-07-11 3:41 ` Stefan Monnier
2011-07-11 9:43 ` martin rudalics
2011-07-09 19:25 ` Chong Yidong
2011-07-10 9:00 ` martin rudalics
2011-07-10 13:09 ` Chong Yidong
2011-07-10 13:31 ` martin rudalics
2011-07-11 3:45 ` Stefan Monnier
2011-07-11 14:56 ` Chong Yidong
2011-07-12 4:25 ` Stefan Monnier
2011-07-12 8:36 ` martin rudalics
2011-07-13 15:42 ` Chong Yidong
2011-07-13 17:18 ` martin rudalics
2011-07-13 21:53 ` Chong Yidong
2011-07-09 8:45 ` martin rudalics
-- strict thread matches above, loose matches on Subject: below --
2011-07-13 22:13 grischka
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.