bug#68679: 30.0.50; Burying a buffer shows an already displayed buffer

bug#68679: 30.0.50; Burying a buffer shows an already displayed buffer

[Sam Steingold]

ISTR that quit-window and bury-buffer made sure that the
replacement/newly displayed buffer is not shown in any other window (at
least that was my intention when I wrote quit-window many years ago).

Right now I see that C-x b (switch-to-buffer) offers a good candidate
(IOW, other-buffer returns a buffer that is not currently shown), but
both quit-window and bury-buffer replace the current buffer with one
that is already displayed in another window in the current frame.

Is there a way to restore the original behavior of never displaying an
already visible buffer?

Is this a (known) bug?

Thank you!

(https://emacs.stackexchange.com/q/80138/795)



In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2024-01-12 built on pop-os
Repository revision: 8b7a6d7b6deca9346092501dbfa679e3e5ea5892
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101004
System Description: Pop!_OS 22.04 LTS

Configured using:
 'configure --with-mailutils --with-native-compilation
 --with-imagemagick --with-native-image-api'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ IMAGEMAGICK
JPEG JSON LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: C
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Shell

Minor modes in effect:
  shell-dirtrack-mode: t
  pyvenv-mode: t
  comint-fontify-input-mode: t
  global-atomic-chrome-edit-mode: t
  global-edit-server-edit-mode: t
  server-mode: t
  winner-mode: t
  which-function-mode: t
  url-handler-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Memory information:
((conses 16 1179154 1747372) (symbols 48 45559 106) (strings 32 346009 122184)
 (string-bytes 1 11220588) (vectors 16 123283) (vector-slots 8 2866890 496408)
 (floats 8 1195 18070) (intervals 56 24806 20570) (buffers 984 73))

-- 
Sam Steingold (https://aphar.dreamwidth.org/) on Pop 22.04 (jammy) X 11.0.12101004
https://lastingimpactpsychology.com https://steingoldpsychology.com
https://www.memritv.org https://www.dhimmitude.org https://ffii.org
A year spent in artificial intelligence is enough to make one believe in God.

bug#68679: 30.0.50; Burying a buffer shows an already displayed buffer

[Eli Zaretskii]

> From: Sam Steingold <sds@gnu.org>
> Date: Tue, 23 Jan 2024 19:11:53 -0500
> 
> ISTR that quit-window and bury-buffer made sure that the
> replacement/newly displayed buffer is not shown in any other window (at
> least that was my intention when I wrote quit-window many years ago).
> 
> Right now I see that C-x b (switch-to-buffer) offers a good candidate
> (IOW, other-buffer returns a buffer that is not currently shown), but
> both quit-window and bury-buffer replace the current buffer with one
> that is already displayed in another window in the current frame.
> 
> Is there a way to restore the original behavior of never displaying an
> already visible buffer?
> 
> Is this a (known) bug?

Where did you see such promises from these two commands?

Adding Martin, in case he has some comments and pointers.

bug#68679: 30.0.50; Burying a buffer shows an already displayed buffer

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

 >> ISTR that quit-window and bury-buffer made sure that the
 >> replacement/newly displayed buffer is not shown in any other window (at
 >> least that was my intention when I wrote quit-window many years ago).
 >>
 >> Right now I see that C-x b (switch-to-buffer) offers a good candidate
 >> (IOW, other-buffer returns a buffer that is not currently shown), but
 >> both quit-window and bury-buffer replace the current buffer with one
 >> that is already displayed in another window in the current frame.

More precisely "may replace".

 >> Is there a way to restore the original behavior of never displaying an
 >> already visible buffer?
 >>
 >> Is this a (known) bug?

Can you try customizing 'switch-to-prev-buffer-skip'?

martin

bug#68679: 30.0.50; Burying a buffer shows an already displayed buffer

[Eli Zaretskii]

> Date: Thu, 25 Jan 2024 10:40:07 +0100
> Cc: 68679@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  >> ISTR that quit-window and bury-buffer made sure that the
>  >> replacement/newly displayed buffer is not shown in any other window (at
>  >> least that was my intention when I wrote quit-window many years ago).
>  >>
>  >> Right now I see that C-x b (switch-to-buffer) offers a good candidate
>  >> (IOW, other-buffer returns a buffer that is not currently shown), but
>  >> both quit-window and bury-buffer replace the current buffer with one
>  >> that is already displayed in another window in the current frame.
> 
> More precisely "may replace".
> 
>  >> Is there a way to restore the original behavior of never displaying an
>  >> already visible buffer?
>  >>
>  >> Is this a (known) bug?
> 
> Can you try customizing 'switch-to-prev-buffer-skip'?

Ping!  Sam, can you try Martin's suggestion and tell if it solves your
problem?

bug#68679: 30.0.50; Burying a buffer shows an already displayed buffer

[Eli Zaretskii]

Ping! Ping!  Sam, can you please try Martin's suggestion?

> Cc: 68679@debbugs.gnu.org, sds@gnu.org
> Date: Thu, 01 Feb 2024 11:49:50 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Date: Thu, 25 Jan 2024 10:40:07 +0100
> > Cc: 68679@debbugs.gnu.org
> > From: martin rudalics <rudalics@gmx.at>
> > 
> >  >> ISTR that quit-window and bury-buffer made sure that the
> >  >> replacement/newly displayed buffer is not shown in any other window (at
> >  >> least that was my intention when I wrote quit-window many years ago).
> >  >>
> >  >> Right now I see that C-x b (switch-to-buffer) offers a good candidate
> >  >> (IOW, other-buffer returns a buffer that is not currently shown), but
> >  >> both quit-window and bury-buffer replace the current buffer with one
> >  >> that is already displayed in another window in the current frame.
> > 
> > More precisely "may replace".
> > 
> >  >> Is there a way to restore the original behavior of never displaying an
> >  >> already visible buffer?
> >  >>
> >  >> Is this a (known) bug?
> > 
> > Can you try customizing 'switch-to-prev-buffer-skip'?
> 
> Ping!  Sam, can you try Martin's suggestion and tell if it solves your
> problem?
> 
> 
> 
> 

bug#68679: 30.0.50; Burying a buffer shows an already displayed buffer

[Eli Zaretskii]

Ping! Ping! Ping!  Sam, any success in trying Martin's suggestion?

> Cc: rudalics@gmx.at, 68679@debbugs.gnu.org
> Date: Sat, 10 Feb 2024 10:28:14 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> Ping! Ping!  Sam, can you please try Martin's suggestion?
> 
> > Cc: 68679@debbugs.gnu.org, sds@gnu.org
> > Date: Thu, 01 Feb 2024 11:49:50 +0200
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > Date: Thu, 25 Jan 2024 10:40:07 +0100
> > > Cc: 68679@debbugs.gnu.org
> > > From: martin rudalics <rudalics@gmx.at>
> > > 
> > >  >> ISTR that quit-window and bury-buffer made sure that the
> > >  >> replacement/newly displayed buffer is not shown in any other window (at
> > >  >> least that was my intention when I wrote quit-window many years ago).
> > >  >>
> > >  >> Right now I see that C-x b (switch-to-buffer) offers a good candidate
> > >  >> (IOW, other-buffer returns a buffer that is not currently shown), but
> > >  >> both quit-window and bury-buffer replace the current buffer with one
> > >  >> that is already displayed in another window in the current frame.
> > > 
> > > More precisely "may replace".
> > > 
> > >  >> Is there a way to restore the original behavior of never displaying an
> > >  >> already visible buffer?
> > >  >>
> > >  >> Is this a (known) bug?
> > > 
> > > Can you try customizing 'switch-to-prev-buffer-skip'?
> > 
> > Ping!  Sam, can you try Martin's suggestion and tell if it solves your
> > problem?
> > 
> > 
> > 
> > 
> 
> 
> 
>