unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Allow controlling the effect of visibility on buffer switching
@ 2022-01-26  9:10 Thuna
  2022-01-26 13:30 ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Thuna @ 2022-01-26  9:10 UTC (permalink / raw)
  To: emacs-devel

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

Currently `read-buffer-to-switch' defaults to non-visible buffers.  An
option to control this behavior could be introduced as follows (a
proof-of-concept, subject to change):


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-controlling-the-effect-of-visibility-on-buffer.patch --]
[-- Type: text/x-diff, Size: 1441 bytes --]

From a4c2d922e2fc0cd48c95df9622d6f06541f38901 Mon Sep 17 00:00:00 2001
From: Thuna <thuna.cing@gmail.com>
Date: Wed, 26 Jan 2022 11:56:17 +0300
Subject: [PATCH] Allow controlling the effect of visibility on buffer
 switching

---
 lisp/window.el | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/lisp/window.el b/lisp/window.el
index 582600e1c6..ffc09486ef 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -8575,6 +8575,12 @@ display-comint-buffer-action
   :group 'windows
   :group 'comint)
 
+(defcustom switch-to-buffer-ignore-visibility nil
+  "If nil, `read-buffer-to-switch' prefer buffers not visible as
+the default buffer to switch to."
+  :type 'boolean
+  :group 'windows)
+
 (defun read-buffer-to-switch (prompt)
   "Read the name of a buffer to switch to, prompting with PROMPT.
 Return the name of the buffer as a string.
@@ -8595,7 +8601,9 @@ read-buffer-to-switch
               (setq-local icomplete-with-completion-tables
                           (cons rbts-completion-table
                                 icomplete-with-completion-tables))))
-      (read-buffer prompt (other-buffer (current-buffer))
+      (read-buffer prompt
+                   (other-buffer (current-buffer)
+                                 switch-to-buffer-ignore-visibility)
                    (confirm-nonexistent-file-or-buffer)))))
 
 (defun window-normalize-buffer-to-switch-to (buffer-or-name)
-- 
2.25.1


[-- Attachment #3: Type: text/plain, Size: 256 bytes --]


There are other functions that might need to have this change applied to
them as well, I imagine.

Autocompletion frameworks would also need to adapt; helm and ivy would
need to fix `helm-mode--read-buffer-to-switch' and `ivy-switch-buffer'
respectively.

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-26  9:10 Allow controlling the effect of visibility on buffer switching Thuna
@ 2022-01-26 13:30 ` Eli Zaretskii
  2022-01-26 13:46   ` Thuna
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-01-26 13:30 UTC (permalink / raw)
  To: Thuna; +Cc: emacs-devel

> From: Thuna <thuna.cing@gmail.com>
> Date: Wed, 26 Jan 2022 12:10:38 +0300
> 
> Currently `read-buffer-to-switch' defaults to non-visible buffers.  An
> option to control this behavior could be introduced as follows (a
> proof-of-concept, subject to change):

Thanks, but why do we need such an option, given that we have
buffer-change history, and so the visible buffers are usually just a
couple of keystrokes away, like M-n?



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-26 13:30 ` Eli Zaretskii
@ 2022-01-26 13:46   ` Thuna
  2022-01-26 15:01     ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Thuna @ 2022-01-26 13:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel


> Thanks, but why do we need such an option, given that we have
> buffer-change history, and so the visible buffers are usually just a
> couple of keystrokes away, like M-n?

If a buffer is open in multiple windows and one of these windows is
momentarily switched off of to look at something else, it is unintuitive
for buffer switching to default to a non-visible buffer instead of the
previously open buffer.  More often than not, a quick [C-x b RET] is,
and should be, sufficient for switching buffers.  Forcing the user to
actively choose the buffer they want introduces unnecessary burden which
can be a significant source of distraction over time.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-26 13:46   ` Thuna
@ 2022-01-26 15:01     ` Eli Zaretskii
  2022-01-27  3:18       ` Matt Armstrong
                         ` (3 more replies)
  0 siblings, 4 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-01-26 15:01 UTC (permalink / raw)
  To: Thuna; +Cc: emacs-devel

> From: Thuna <thuna.cing@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 26 Jan 2022 16:46:32 +0300
> 
> 
> > Thanks, but why do we need such an option, given that we have
> > buffer-change history, and so the visible buffers are usually just a
> > couple of keystrokes away, like M-n?
> 
> If a buffer is open in multiple windows and one of these windows is
> momentarily switched off of to look at something else, it is unintuitive
> for buffer switching to default to a non-visible buffer instead of the
> previously open buffer.  More often than not, a quick [C-x b RET] is,
> and should be, sufficient for switching buffers.  Forcing the user to
> actively choose the buffer they want introduces unnecessary burden which
> can be a significant source of distraction over time.

Forcing users to learn too many options is also not a very good idea,
and we already have gobs of them.  So much so that even the head
maintainers don't remember that many of them exist.

So I'm asking whether "C-x b M-n RET" is not a good enough solution
for this use case?  Does anyone else have an opinion?



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-26 15:01     ` Eli Zaretskii
@ 2022-01-27  3:18       ` Matt Armstrong
  2022-01-27 18:16         ` Thuna
  2022-01-27  4:25       ` Michael Welsh Duggan
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 19+ messages in thread
From: Matt Armstrong @ 2022-01-27  3:18 UTC (permalink / raw)
  To: Eli Zaretskii, Thuna; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thuna <thuna.cing@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 26 Jan 2022 16:46:32 +0300
>> 
>> 
>> > Thanks, but why do we need such an option, given that we have
>> > buffer-change history, and so the visible buffers are usually just a
>> > couple of keystrokes away, like M-n?
>> 
>> If a buffer is open in multiple windows and one of these windows is
>> momentarily switched off of to look at something else, it is unintuitive
>> for buffer switching to default to a non-visible buffer instead of the
>> previously open buffer.  More often than not, a quick [C-x b RET] is,
>> and should be, sufficient for switching buffers.  Forcing the user to
>> actively choose the buffer they want introduces unnecessary burden which
>> can be a significant source of distraction over time.
>
> Forcing users to learn too many options is also not a very good idea,
> and we already have gobs of them.  So much so that even the head
> maintainers don't remember that many of them exist.
>
> So I'm asking whether "C-x b M-n RET" is not a good enough solution
> for this use case?  Does anyone else have an opinion?

I might be one person that at least tries this patch out, but I think it
would take me a while to figure out if I like it.

In 25 years I haven't picked up on the idea that C-x b RET could be a
quick "get me back to the previous buffer" habbit, probably because it
doesn't always work.

I sometimes keep multiple frames open and forget what is going on in the
other frame.  In this disorganized state, the "Buffers not visible in
windows are preferred to visible buffers" feature just means Emacs acts
strangely.

I sometimes split a frame to look at different parts of the same buffer.
This changes what C-x b RET does.

Thuna, have you used this patch for a while and found it to your liking?



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-26 15:01     ` Eli Zaretskii
  2022-01-27  3:18       ` Matt Armstrong
@ 2022-01-27  4:25       ` Michael Welsh Duggan
  2022-01-27 17:09       ` Juri Linkov
  2022-01-29  7:48       ` Thuna
  3 siblings, 0 replies; 19+ messages in thread
From: Michael Welsh Duggan @ 2022-01-27  4:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Thuna, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thuna <thuna.cing@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 26 Jan 2022 16:46:32 +0300
>> 
>> 
>> > Thanks, but why do we need such an option, given that we have
>> > buffer-change history, and so the visible buffers are usually just a
>> > couple of keystrokes away, like M-n?
>> 
>> If a buffer is open in multiple windows and one of these windows is
>> momentarily switched off of to look at something else, it is unintuitive
>> for buffer switching to default to a non-visible buffer instead of the
>> previously open buffer.  More often than not, a quick [C-x b RET] is,
>> and should be, sufficient for switching buffers.  Forcing the user to
>> actively choose the buffer they want introduces unnecessary burden which
>> can be a significant source of distraction over time.
>
> Forcing users to learn too many options is also not a very good idea,
> and we already have gobs of them.  So much so that even the head
> maintainers don't remember that many of them exist.
>
> So I'm asking whether "C-x b M-n RET" is not a good enough solution
> for this use case?  Does anyone else have an opinion?

I can say that I have wanted this behavior for a long time.  I do not
know that I would have considered "M-n" as an option to get this.  In
some limited tests that I have done, I have to hit "M-n" twice to get
the desired behavior.  I often have the same buffer open in multiple
frames so I can look at different parts of a buffer at the same time.  I
really want the buffer history for a window to not consider whether that
buffer is already visible in another frame (which, for me, might be on
another desktop entirely, and, as such, not really visible at all).

-- 
Michael Welsh Duggan
(md5i@md5i.com)



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-26 15:01     ` Eli Zaretskii
  2022-01-27  3:18       ` Matt Armstrong
  2022-01-27  4:25       ` Michael Welsh Duggan
@ 2022-01-27 17:09       ` Juri Linkov
  2022-01-29  7:48       ` Thuna
  3 siblings, 0 replies; 19+ messages in thread
From: Juri Linkov @ 2022-01-27 17:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Thuna, emacs-devel

> So I'm asking whether "C-x b M-n RET" is not a good enough solution
> for this use case?  Does anyone else have an opinion?

I agree that "C-x b M-n RET" is a good enough solution.
Then the list for M-n could be sorted by recency of visiting buffers.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-27  3:18       ` Matt Armstrong
@ 2022-01-27 18:16         ` Thuna
  0 siblings, 0 replies; 19+ messages in thread
From: Thuna @ 2022-01-27 18:16 UTC (permalink / raw)
  To: Matt Armstrong; +Cc: Eli Zaretskii, emacs-devel


> Thuna, have you used this patch for a while and found it to your liking?

I am in the same situation where because it doesn't/didn't work
reliably, I haven't fully managed to get used to it; I end up freezing
up at the select buffer menu occasionally.  Nevertheless, when it works,
I don't pay much attention to it (which in my opinion is a good sign).



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-26 15:01     ` Eli Zaretskii
                         ` (2 preceding siblings ...)
  2022-01-27 17:09       ` Juri Linkov
@ 2022-01-29  7:48       ` Thuna
  2022-01-29  8:14         ` Eli Zaretskii
  2022-01-29  9:37         ` Po Lu
  3 siblings, 2 replies; 19+ messages in thread
From: Thuna @ 2022-01-29  7:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel


> Forcing users to learn too many options is also not a very good idea,
> and we already have gobs of them.  So much so that even the head
> maintainers don't remember that many of them exist.

If the proposal is rejected on this basis, I would like to revise it
from "introducing an option to change the behavior of switch-to-buffer"
to "changing the behavior of switch-to-buffer".

It is extremely unlikely for someone to know what their last non-visible
buffer is, especially after accounting for other frames and windows.
People are better off typing the name of the buffer they want to visit.
Compared to that, switching to the last buffer is considerably more
manageable and useful.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-29  7:48       ` Thuna
@ 2022-01-29  8:14         ` Eli Zaretskii
  2022-01-29  8:35           ` Thuna
  2022-01-29  9:37         ` Po Lu
  1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-01-29  8:14 UTC (permalink / raw)
  To: Thuna; +Cc: emacs-devel

> From: Thuna <thuna.cing@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 29 Jan 2022 10:48:08 +0300
> 
> If the proposal is rejected on this basis, I would like to revise it
> from "introducing an option to change the behavior of switch-to-buffer"
> to "changing the behavior of switch-to-buffer".
> 
> It is extremely unlikely for someone to know what their last non-visible
> buffer is, especially after accounting for other frames and windows.

Maybe I don't understand what you mean, but "C-x b" shows the buffer
it would switch to in the prompt, and AFAIU that is the "last
non-visible buffer" to which you allude above, right?

> People are better off typing the name of the buffer they want to visit.

I'd think Emacs users are well familiar with the history feature, and
are using M-p and M-n frequently, instead of actually typing the
buffer names.  I only type the buffer name if several M-p's and M-n's
don't bring them up.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-29  8:14         ` Eli Zaretskii
@ 2022-01-29  8:35           ` Thuna
  0 siblings, 0 replies; 19+ messages in thread
From: Thuna @ 2022-01-29  8:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel


> Maybe I don't understand what you mean, but "C-x b" shows the buffer
> it would switch to in the prompt, and AFAIU that is the "last
> non-visible buffer" to which you allude above, right?

It is usually the case that people have a specific buffer in mind that
they want to switch to.  If they know that that specific buffer is the
last, be it visible or non-visible, buffer that they visited, then they
can save time by hitting RET without seeing the default.  My point here
was that it is much more likely that someone knows what their last
buffer is than it is that someone knows what their last /non-visible/
buffer is.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-29  7:48       ` Thuna
  2022-01-29  8:14         ` Eli Zaretskii
@ 2022-01-29  9:37         ` Po Lu
  2022-01-29 15:27           ` Michael Welsh Duggan
  2022-01-30  0:31           ` Stefan Monnier
  1 sibling, 2 replies; 19+ messages in thread
From: Po Lu @ 2022-01-29  9:37 UTC (permalink / raw)
  To: Thuna; +Cc: Eli Zaretskii, emacs-devel

Thuna <thuna.cing@gmail.com> writes:

> It is extremely unlikely for someone to know what their last non-visible
> buffer is, especially after accounting for other frames and windows.

I find it sufficient to take a quick glance at the frame I'm currently
working on.  Further more, multiple frame workflows are reasonably rare,
and even more so the workflows where some frames aren't visible at any
given time.

And please don't change the behaviour of `switch-to-buffer' in such a
drastic manner.  People are used to it as it is.

Thanks.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-29  9:37         ` Po Lu
@ 2022-01-29 15:27           ` Michael Welsh Duggan
  2022-01-29 20:03             ` chad
  2022-01-30  0:31           ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: Michael Welsh Duggan @ 2022-01-29 15:27 UTC (permalink / raw)
  To: Po Lu; +Cc: Eli Zaretskii, Thuna, emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> Thuna <thuna.cing@gmail.com> writes:
>
>> It is extremely unlikely for someone to know what their last non-visible
>> buffer is, especially after accounting for other frames and windows.
>
> I find it sufficient to take a quick glance at the frame I'm currently
> working on.  Further more, multiple frame workflows are reasonably rare,
> and even more so the workflows where some frames aren't visible at any
> given time.
>
> And please don't change the behaviour of `switch-to-buffer' in such a
> drastic manner.  People are used to it as it is.

On the other hand, I've hated the current behavior for years (as does a
colleague of mine), and it is not an easy behavior to patch in one's
local emacs, as it is buried too deeply.  I would like some way to patch
this without having to copy the innards of read-buffer-to-switch.  I
personally think that Thuna's patch is ideal, since it doesn't change
the current behavior by default but makes it easy for those of us who
want it to change to do so.  But I would take any change that makes it
easier to patch in what we consider more desirable behavior.

-- 
Michael Welsh Duggan
(md5i@md5i.com)



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-29 15:27           ` Michael Welsh Duggan
@ 2022-01-29 20:03             ` chad
  2022-01-30  7:06               ` Po Lu
  0 siblings, 1 reply; 19+ messages in thread
From: chad @ 2022-01-29 20:03 UTC (permalink / raw)
  To: Michael Welsh Duggan; +Cc: Po Lu, Eli Zaretskii, Thuna, EMACS development team

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

On Sat, Jan 29, 2022 at 10:28 AM Michael Welsh Duggan <mwd@md5i.com> wrote:

> Po Lu <luangruo@yahoo.com> writes:
> > And please don't change the behaviour of `switch-to-buffer' in such a
> > drastic manner.  People are used to it as it is.
>
> On the other hand, I've hated the current behavior for years (as does a
> colleague of mine),
>

There are a /lot/ of packages that replace switch-to-buffer. Helm, Ivy, and
all seem to have one, as well as a plethora of stand-alone packages.
Looking at any website where users ask for help with emacs shows lots of
questions on this topic, generally answered by people suggesting packages
or elisp snippets like "switch-to-last-buffer" or
"switch-to-previous-buffer" or "iflipb" (these three garnered from <15
seconds of searching). I myself used a customized bury-buffer alternative
for years (since before there were websites), then switched to an
alternative next-frame-or-buffer based around a macOS ui pattern on \M-`
for my decade+ in that world, and am now trying something new (since the
window manager I'm more or less stuck with on my current linux-based system
interacts badly with the M-` workflow).

My point being: I'm sure that there are people who "are used to it as it",
and that's evidenced by the large number of people who are used to it being
unusable as-is. I think there's a reasonable argument to be made for not
changing the default, but I also think that there's at least enough
evidence to support an emacs-standard option.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 2065 bytes --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-29  9:37         ` Po Lu
  2022-01-29 15:27           ` Michael Welsh Duggan
@ 2022-01-30  0:31           ` Stefan Monnier
  2022-01-30  6:42             ` Eli Zaretskii
  1 sibling, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-01-30  0:31 UTC (permalink / raw)
  To: Po Lu; +Cc: Thuna, Eli Zaretskii, emacs-devel

Po Lu [2022-01-29 17:37:40] wrote:
> Thuna <thuna.cing@gmail.com> writes:
>> It is extremely unlikely for someone to know what their last non-visible
>> buffer is, especially after accounting for other frames and windows.
>
> I find it sufficient to take a quick glance at the frame I'm currently
> working on.  Further more, multiple frame workflows are reasonably rare,
> and even more so the workflows where some frames aren't visible at any
> given time.

FWIW, I also dislike the current behavior: I can't remember the last
time that I used `C-x b`s default and was glad that it wasn't one
of the already displayed buffers: for my use cases, `C-x b`s default is
only ever right when the last buffer is not visible.

> And please don't change the behaviour of `switch-to-buffer' in such a
> drastic manner.  People are used to it as it is.

I think this discussion would benefit from a more constructive argument
than habit.  Can you describe use cases where `C-x b`s current default
is indeed the one the user wants yet it is not the last buffer (because
the last buffer is already visible elsewhere)?

My analysis of the situation is the following:

- Users in group A arrange to (almost always) have one one window
  displaying a given buffer.  In that case, they probably won't want to
  `C-x b` to an already visible buffer (which suggests the current code
  is right for them) *BUT* it also means that the "last buffer" is most
  likely not visible either (since it would mean that this last buffer
  was (back then) visible in two windows).
  So for those users, either behavior will usually give the same result.

- Users in group B OTOH do take advantage of Emacs's (maybe not unique,
  but somewhat unusual) ability to display the same buffer is several
  windows at the same time.  For them it's just as likely they'll want
  to use `C-x b` to display an already displayed buffer as any other.
  For these users, the current behavior may be harmful since it just
  makes it harder for them to predict what `C-x b`s default will be.


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-30  0:31           ` Stefan Monnier
@ 2022-01-30  6:42             ` Eli Zaretskii
  2022-01-30 16:08               ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-01-30  6:42 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: luangruo, thuna.cing, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Thuna <thuna.cing@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Sat, 29 Jan 2022 19:31:06 -0500
> 
> I think this discussion would benefit from a more constructive argument
> than habit.  Can you describe use cases where `C-x b`s current default
> is indeed the one the user wants yet it is not the last buffer (because
> the last buffer is already visible elsewhere)?

I can: when I mistakenly display (or cause Emacs to display) a buffer
in the wrong window/frame.  Then the fix is:

   . C-x b RET
   . go to the "correct" window/frame
   . C-x b RET

> - Users in group A arrange to (almost always) have one one window
>   displaying a given buffer.  In that case, they probably won't want to
>   `C-x b` to an already visible buffer (which suggests the current code
>   is right for them) *BUT* it also means that the "last buffer" is most
>   likely not visible either (since it would mean that this last buffer
>   was (back then) visible in two windows).
>   So for those users, either behavior will usually give the same result.
> 
> - Users in group B OTOH do take advantage of Emacs's (maybe not unique,
>   but somewhat unusual) ability to display the same buffer is several
>   windows at the same time.  For them it's just as likely they'll want
>   to use `C-x b` to display an already displayed buffer as any other.
>   For these users, the current behavior may be harmful since it just
>   makes it harder for them to predict what `C-x b`s default will be.

I'm in group B, but as I said earlier "C-x b M-n M-n" does the job
nicely, and the "C-x b"s default is important in some use cases.  (I
think in general disregarding the M-n/M-p history features in this
discussion makes it lopsided.)



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-29 20:03             ` chad
@ 2022-01-30  7:06               ` Po Lu
  0 siblings, 0 replies; 19+ messages in thread
From: Po Lu @ 2022-01-30  7:06 UTC (permalink / raw)
  To: chad; +Cc: Michael Welsh Duggan, Eli Zaretskii, Thuna,
	EMACS development team

chad <yandros@gmail.com> writes:

> There are a /lot/ of packages that replace switch-to-buffer. Helm,
> Ivy, and all seem to have one

Yet they don't change which buffer is the default, AFAICT.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-30  6:42             ` Eli Zaretskii
@ 2022-01-30 16:08               ` Stefan Monnier
  2022-01-30 16:51                 ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Stefan Monnier @ 2022-01-30 16:08 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, thuna.cing, emacs-devel

>> I think this discussion would benefit from a more constructive argument
>> than habit.  Can you describe use cases where `C-x b`s current default
>> is indeed the one the user wants yet it is not the last buffer (because
>> the last buffer is already visible elsewhere)?
>
> I can: when I mistakenly display (or cause Emacs to display) a buffer
> in the wrong window/frame.  Then the fix is:
>
>    . C-x b RET
>    . go to the "correct" window/frame
>    . C-x b RET

Hmm... I don't understand why you think this is an example: the first
`C-x b` will only be guaranteed to do what you intended if `C-x b`
chooses "the latest buffer" rather than "the latest buffer that's not
visible", so it seems to be an argument in favor of the proposed change.

What am I missing?


        Stefan




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Allow controlling the effect of visibility on buffer switching
  2022-01-30 16:08               ` Stefan Monnier
@ 2022-01-30 16:51                 ` Eli Zaretskii
  0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-01-30 16:51 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: luangruo, thuna.cing, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: luangruo@yahoo.com,  thuna.cing@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 30 Jan 2022 11:08:59 -0500
> 
> >> I think this discussion would benefit from a more constructive argument
> >> than habit.  Can you describe use cases where `C-x b`s current default
> >> is indeed the one the user wants yet it is not the last buffer (because
> >> the last buffer is already visible elsewhere)?
> >
> > I can: when I mistakenly display (or cause Emacs to display) a buffer
> > in the wrong window/frame.  Then the fix is:
> >
> >    . C-x b RET
> >    . go to the "correct" window/frame
> >    . C-x b RET
> 
> Hmm... I don't understand why you think this is an example: the first
> `C-x b` will only be guaranteed to do what you intended if `C-x b`
> chooses "the latest buffer" rather than "the latest buffer that's not
> visible", so it seems to be an argument in favor of the proposed change.

I meant the second "C-x b", not the first.  The first just removes the
mistaken display from the "wrong" window.



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-01-30 16:51 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-01-26  9:10 Allow controlling the effect of visibility on buffer switching Thuna
2022-01-26 13:30 ` Eli Zaretskii
2022-01-26 13:46   ` Thuna
2022-01-26 15:01     ` Eli Zaretskii
2022-01-27  3:18       ` Matt Armstrong
2022-01-27 18:16         ` Thuna
2022-01-27  4:25       ` Michael Welsh Duggan
2022-01-27 17:09       ` Juri Linkov
2022-01-29  7:48       ` Thuna
2022-01-29  8:14         ` Eli Zaretskii
2022-01-29  8:35           ` Thuna
2022-01-29  9:37         ` Po Lu
2022-01-29 15:27           ` Michael Welsh Duggan
2022-01-29 20:03             ` chad
2022-01-30  7:06               ` Po Lu
2022-01-30  0:31           ` Stefan Monnier
2022-01-30  6:42             ` Eli Zaretskii
2022-01-30 16:08               ` Stefan Monnier
2022-01-30 16:51                 ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).