GNU bug report logs - #68679
30.0.50; Burying a buffer shows an already displayed buffer

Previous Next

To reply to this bug, email your comments to 68679 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sam Steingold <sds <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; Burying a buffer shows an already displayed buffer
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?

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.

Message #8 received at 68679 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sds <at> gnu.org, martin rudalics <rudalics <at> gmx.at>
Cc: 68679 <at> debbugs.gnu.org
Subject: Re: bug#68679: 30.0.50;
 Burying a buffer shows an already displayed buffer
Date: Wed, 24 Jan 2024 14:28:26 +0200

> From: Sam Steingold <sds <at> 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.

Message #11 received at 68679 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, sds <at> gnu.org
Cc: 68679 <at> debbugs.gnu.org
Subject: Re: bug#68679: 30.0.50; Burying a buffer shows an already displayed
 buffer
Date: Thu, 25 Jan 2024 10:40:07 +0100

>> 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

Message #14 received at 68679 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 68679 <at> debbugs.gnu.org, sds <at> gnu.org
Subject: Re: bug#68679: 30.0.50; Burying a buffer shows an already displayed
 buffer
Date: Thu, 01 Feb 2024 11:49:50 +0200

> Date: Thu, 25 Jan 2024 10:40:07 +0100
> Cc: 68679 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> 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?

Message #17 received at 68679 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sds <at> gnu.org
Cc: rudalics <at> gmx.at, 68679 <at> debbugs.gnu.org
Subject: Re: bug#68679: 30.0.50;
 Burying a buffer shows an already displayed buffer
Date: Sat, 10 Feb 2024 10:28:14 +0200

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

> Cc: 68679 <at> debbugs.gnu.org, sds <at> gnu.org
> Date: Thu, 01 Feb 2024 11:49:50 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > Date: Thu, 25 Jan 2024 10:40:07 +0100
> > Cc: 68679 <at> debbugs.gnu.org
> > From: martin rudalics <rudalics <at> 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?
> 
> 
> 
> 

Message #20 received at 68679 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sds <at> gnu.org
Cc: rudalics <at> gmx.at, 68679 <at> debbugs.gnu.org
Subject: Re: bug#68679: 30.0.50;
 Burying a buffer shows an already displayed buffer
Date: Sat, 17 Feb 2024 10:26:29 +0200

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

> Cc: rudalics <at> gmx.at, 68679 <at> debbugs.gnu.org
> Date: Sat, 10 Feb 2024 10:28:14 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Ping! Ping!  Sam, can you please try Martin's suggestion?
> 
> > Cc: 68679 <at> debbugs.gnu.org, sds <at> gnu.org
> > Date: Thu, 01 Feb 2024 11:49:50 +0200
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > 
> > > Date: Thu, 25 Jan 2024 10:40:07 +0100
> > > Cc: 68679 <at> debbugs.gnu.org
> > > From: martin rudalics <rudalics <at> 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?
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.