bug#52467: 29.0.50; Use pop-to-buffer for shell

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Steingold]

Hi
I would like to request reverting of the patch

70b64e0d040e9c57f1a489c9ebee553264033119 "Use pop-to-buffer-same-window for shell"

When I already have a window with shell, this patch creates a second
such window.
It seems much more reasonable to use pop-to-buffer in eshell rather than
break shell's behavior.

If you insist on your desired behavior, please add a user variable
`shell-pop-to-buffer-action` that you would set to
`display-buffer--same-window-action`.

Thank you.

In GNU Emacs 29.0.50 (build 2, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H1519))
 of 2021-12-06 built on 3c22fb11fdab.ant.amazon.com
Repository revision: dd2a994f0c6b8e0f725299a5b3a871578ed9d3e4
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7


-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1894
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://honestreporting.com https://jij.org https://ffii.org https://camera.org
Time would have been the best Teacher, if it did not kill all its students.

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Dmitry Gutov]

On 13.12.2021 19:16, Steingold wrote:
> It seems much more reasonable to use pop-to-buffer in eshell rather than
> break shell's behavior.

That seems reasonable too.

I think we'll do whatever the maintainers decide on this issue.

bug#52467: 29.0.50; Use pop-to-buffer for shell

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

On 13 December 2021 22:14:31 CET, Dmitry Gutov <dgutov@yandex.ru> wrote:
>On 13.12.2021 19:16, Steingold wrote:
>> It seems much more reasonable to use pop-to-buffer in eshell rather than
>> break shell's behavior.
>
>That seems reasonable too.
>

I don't have any objections, but not my call. 


>I think we'll do whatever the maintainers decide on this issue.

Agreed! 

Theo

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 13.12.2021 19:16, Steingold wrote:
>> It seems much more reasonable to use pop-to-buffer in eshell rather than
>> break shell's behavior.
>
> That seems reasonable too.
>
> I think we'll do whatever the maintainers decide on this issue.

I think the current behaviour makes more sense than the old one, really.
For one, it's more predictable -- when you say `M-x shell', you're
getting a shell in the current buffer.  The old behaviour either does
that, or lands you in a different window (if you've already got a shell
buffer open elsewhere), right?

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

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Dmitry Gutov]

On 19.12.2021 16:14, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 13.12.2021 19:16, Steingold wrote:
>>> It seems much more reasonable to use pop-to-buffer in eshell rather than
>>> break shell's behavior.
>>
>> That seems reasonable too.
>>
>> I think we'll do whatever the maintainers decide on this issue.
> 
> I think the current behaviour makes more sense than the old one, really.
> For one, it's more predictable -- when you say `M-x shell', you're
> getting a shell in the current buffer.

In the current _window_, right?

 >The old behaviour either does
> that, or lands you in a different window (if you've already got a shell
> buffer open elsewhere), right?

To be fair, it might be considered a little inconsistent still. Like, 
you get a shell (or eshell) buffer in the current window, but if some 
shell/eshell buffer already exists, you get that (existing) buffer in 
the current window.

One could expect something else still: a new buffer in the current 
default-directory. Meaning, an [e]shell buffer that corresponds (in some 
way) to the buffer that was previously displayed in that window.

Or to phrase that in a way similar to yours: a shell buffer in the 
current window that's related to the current buffer.

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>> One could expect something else still: a new buffer in the current
>> default-directory. Meaning, an [e]shell buffer that corresponds (in
>> some way) to
>> the buffer that was previously displayed in that window.

Yes, but...  having a single buffer for things is what we usually do --
*info*, *Help*, etc.

> Isn't that what the prefix argument is for?

Yup.

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

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Sam Steingold]

At this time the current behavior in unpalatable in that I sometimes get
a second window with the same buffer, and there is no way for me to
change it.

Wouldn't it be better to at least use `pop-to-buffer' everywhere and
let the user decide what they prefer using the standard mechanisms like
`display-buffer-base-action' or `display-buffer-alist'?

Thank you!

-- 
Sam Steingold (http://sds.podval.org/) on Pop 21.10 (impish) X 11.0.12013000
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://iris.org.il http://think-israel.org https://memri.org
Bug free software merely has random features.

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Dmitry Gutov]

On 20.12.2021 13:17, Lars Ingebrigtsen wrote:
> Stefan Kangas <stefan@marxist.se> writes:
> 
>>> One could expect something else still: a new buffer in the current
>>> default-directory. Meaning, an [e]shell buffer that corresponds (in
>>> some way) to
>>> the buffer that was previously displayed in that window.
> 
> Yes, but...  having a single buffer for things is what we usually do --
> *info*, *Help*, etc.
> 
>> Isn't that what the prefix argument is for?
> 
> Yup.

That's what I was saying: both "force the use of the current window" and 
"force the use of the current default-directory" could be enabled by the 
use of the prefix argument.

Whereas we currently have the former by default, and the latter on 
prefix argument.

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> That's what I was saying: both "force the use of the current window"
> and "force the use of the current default-directory" could be enabled
> by the use of the prefix argument.
>
> Whereas we currently have the former by default, and the latter on
> prefix argument.

I don't quite get what you mean here.  `M-x shell' pops up the old shell
buffer in the current window.  `C-u M-x shell' pops up a new shell
buffer (started from the current default-directory) in the current
window.  What is that you propose should change?

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

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Dmitry Gutov]

On 24.12.2021 12:07, Lars Ingebrigtsen wrote:
> What is that you propose should change?

Basically what Sam is asking (use pop-to-window for both shell and 
eshell), I'm just trying to conceptualize that change. Not a strong 
preference, but it seems to make sense.

Or to approach the question from another angle, the difference between 
that behavior and the current one is that you can create two windows 
that show the same buffer. Do we want that to happen with 'M-x shell' 
without prefix?

Overall, pop-to-buffer seems more common than pop-to-buffer-same-window.

The downside of using it, though, is that the current window is unlikely 
to be used even if the buffer is not displayed anywhere else (the 
algorithm chooses something like LRU window). Maybe we should choose a 
mode of operation where it does use the current window, unless the 
buffer is displayed somewhere else.

Something like

     (pop-to-buffer buffer
                    '((display-buffer-reuse-window
                       display-buffer-same-window)
                      (inhibit-same-window . nil)))

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> Or to approach the question from another angle, the difference between
> that behavior and the current one is that you can create two windows
> that show the same buffer. Do we want that to happen with 'M-x shell'
> without prefix?

That's how it works today, and it's a simple and predictable way to act
for this command.

> Overall, pop-to-buffer seems more common than pop-to-buffer-same-window.

Well, I think it depends on the command, really.  If it's a command
that's usually used to pop up a new secondary window while you're still
expected to keep on working in the current buffer later, then we pop,
otherwise we switch.  And `M-x shell' is in the "switch" category --
it's a "new action", not "something I'm doing for a bit before going
back to this buffer".

> The downside of using it, though, is that the current window is
> unlikely to be used even if the buffer is not displayed anywhere else
> (the algorithm chooses something like LRU window). Maybe we should
> choose a mode of operation where it does use the current window,
> unless the buffer is displayed somewhere else.
>
> Something like
>
>     (pop-to-buffer buffer
>                    '((display-buffer-reuse-window
>                       display-buffer-same-window)
>                      (inhibit-same-window . nil)))

I think that's more unpredictable.  What happens currently is very regular.

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

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Dmitry Gutov]

On 26.12.2021 14:35, Lars Ingebrigtsen wrote:
> I think that's more unpredictable.  What happens currently is very regular.

That's a fair argument, too.

I suppose that if we changed pop-to-buffer-same-window to behave like I 
suggested, it might be more "regular" as well, but more of a breaking 
change.

In the meantime, people who would like that behavior across the board 
can add this to their init file:

   (setq display-buffer--same-window-action
         '((display-buffer-reuse-window
            display-buffer-same-window)
           (inhibit-same-window . nil)))

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Sam Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2021-12-26 12:35:49 +0100]:
>
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
>> The downside of using it, though, is that the current window is
>> unlikely to be used even if the buffer is not displayed anywhere else
>> (the algorithm chooses something like LRU window). Maybe we should
>> choose a mode of operation where it does use the current window,
>> unless the buffer is displayed somewhere else.
>>
>> Something like
>>
>>     (pop-to-buffer buffer
>>                    '((display-buffer-reuse-window
>>                       display-buffer-same-window)
>>                      (inhibit-same-window . nil)))
>
> I think that's more unpredictable.  What happens currently is very regular.

I think predictability if not the only or even main concern.

The current behavior is _not_ user-customizable, which is a major
problem for me. I hardly ever want the same buffer displayed _twice_,
especially the *shell* buffer.

Whatever default behavior you want (and for me it's definitely
reuse-window) should be implemented using a new user variable
`shell-display-buffer-action' that would be used by `shell',
`project-shell', `eshell', &c.

This is not a major change, so I propose that we close this bug by
adding `shell-display-buffer-action' (I can do that), and continue the
discussion of the best default on emacs-devel.

Thank you.
-- 
Sam Steingold (http://sds.podval.org/) on Pop 21.10 (impish) X 11.0.12013000
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://camera.org https://iris.org.il https://www.memritv.org
MS Windows vs IBM OS/2: Why marketing matters more than technology...

bug#52467: 29.0.50; Use pop-to-buffer for shell

[jakanakaevangeli]

Sam Steingold <sds@gnu.org> writes:

> I think predictability if not the only or even main concern.
>
> The current behavior is _not_ user-customizable, which is a major
> problem for me. I hardly ever want the same buffer displayed _twice_,
> especially the *shell* buffer.
>
> Whatever default behavior you want (and for me it's definitely
> reuse-window) should be implemented using a new user variable
> `shell-display-buffer-action' that would be used by `shell',
> `project-shell', `eshell', &c.

It is user configurable through 'display-buffer-alist, see my other
reply to this thread. To prevent creation of duplicate windows showing
the same shell buffer, do

   (add-to-list 'display-buffer-alist
                '("\\`\\*shell\\*" display-buffer-reuse-window))

For old behaviour of popping up a new shell window, do

   (add-to-list 'display-buffer-alist
                '("\\`\\*shell\\*"
                  (display-buffer-reuse-window display-buffer-pop-up-window)))

The same can be done for eshell, terminal and most other buffers
displayed with 'display-buffer-same-window'.

> This is not a major change, so I propose that we close this bug by
> adding `shell-display-buffer-action' (I can do that), and continue the
> discussion of the best default on emacs-devel.

I'm personally against adding such an user option.

If it were added for M-x shell, eshell and term, the same reasoning
could be used to add it for M-x run-scheme, dired, dunnet and all the
other places using 'pop-to-buffer-same-window'. This would add up to a
lot of variables for little benefit since we can already customize
window pop-up behaviour of all these commands with
'display-buffer-alist'.

> Thank you.

bug#52467: 29.0.50; Use pop-to-buffer for shell

[Lars Ingebrigtsen]

<jakanakaevangeli@chiru.no> writes:

> It is user configurable through 'display-buffer-alist, see my other
> reply to this thread. To prevent creation of duplicate windows showing
> the same shell buffer, do
>
>    (add-to-list 'display-buffer-alist
>                 '("\\`\\*shell\\*" display-buffer-reuse-window))

Yup.

> I'm personally against adding such an user option.
>
> If it were added for M-x shell, eshell and term, the same reasoning
> could be used to add it for M-x run-scheme, dired, dunnet and all the
> other places using 'pop-to-buffer-same-window'. This would add up to a
> lot of variables for little benefit since we can already customize
> window pop-up behaviour of all these commands with
> 'display-buffer-alist'.

Indeed.  So I don't think there's anything that needs to be done here --
the user can customise the behaviour here on a fine grained basis
already, so I'm closing this bug report.

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

bug#52467: 29.0.50; Use pop-to-buffer for shell

[jakanakaevangeli]

Steingold <sds@gnu.org> writes:

> Hi
> I would like to request reverting of the patch
>
> 70b64e0d040e9c57f1a489c9ebee553264033119 "Use pop-to-buffer-same-window for shell"
>
> When I already have a window with shell, this patch creates a second
> such window.

Maybe you could try customizing display-buffer-alist. To prevent
creation of duplicate windows showing the same shell buffer, do

  (add-to-list 'display-buffer-alist
               '("\\`\\*shell\\*\\'" display-buffer-reuse-window))

> It seems much more reasonable to use pop-to-buffer in eshell rather than
> break shell's behavior.

For old behaviour of popping up a new shell window, do

  (add-to-list 'display-buffer-alist
               '("\\`\\*shell\\*\\'"
                 (display-buffer-reuse-window display-buffer-pop-up-window)))

> If you insist on your desired behavior, please add a user variable
> `shell-pop-to-buffer-action` that you would set to
> `display-buffer--same-window-action`.

display-buffer-alist is flexible enough to customize this behaviour, no
need for a new user option in my opinion.

Best regards.