* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
@ 2016-11-28 18:51 Francesco Potortì
2016-11-28 19:14 ` martin rudalics
0 siblings, 1 reply; 9+ messages in thread
From: Francesco Potortì @ 2016-11-28 18:51 UTC (permalink / raw)
To: 25054
If I have the screen divided into two windows showing two different
buffers and issue M-x bury-buffer on one of them, the window will show
the same buffer that is shown in the other window.
This is different from what it was in Emacs 22, and I find it very
annoying. Unless there is good reason for the new behaviour, the buffer
displayed should be the "other buffer". To reproduce:
C-x 1 RET
C-x b a RET
C-x b b RET
C-x b c RET
C-x 4 b d RET
M-x bury-buffer RET
Now both windows show buffer c, while the current buffer should display
buffer b.
In GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2016-10-24, modified by Debian built on trouble
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Debian GNU/Linux testing (stretch)
Configured using:
'configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
--with-sound=alsa --with-x=yes --with-x-toolkit=lucid
--with-toolkit-scroll-bars --without-gconf --without-gsettings
'CFLAGS=-g -O2
-fdebug-prefix-map=/build/emacs25-25.1+1=. -fstack-protector-strong
-Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11
Important settings:
value of $LC_COLLATE: it_IT.UTF-8
value of $LC_CTYPE: it_IT.UTF-8
value of $LC_NUMERIC: C
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: TeX
Minor modes in effect:
longlines-mode: t
desktop-save-mode: t
shell-dirtrack-mode: t
openwith-mode: t
xterm-mouse-mode: t
display-time-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
use-hard-newlines: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
Recent messages:
Showing message 809...done
Showing message 809...done
Showing message 809...done
message learnt as spam
No following nondeleted message
Expunging deleted messages...done
Showing message 808...
Saving file /home/pot/Mail/RMAIL...
Wrote /home/pot/Mail/RMAIL [2 times]
Quit
Load-path shadows:
~/elisp/bhl hides /usr/share/emacs/25.1/site-lisp/bhl
~/elisp/bhl hides /usr/share/emacs/site-lisp/bhl
/usr/share/emacs/25.1/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs25/site-lisp/flim/md4 hides /usr/share/emacs/25.1/lisp/md4
/usr/share/emacs25/site-lisp/flim/hex-util hides /usr/share/emacs/25.1/lisp/hex-util
/usr/share/emacs/site-lisp/rst hides /usr/share/emacs/25.1/lisp/textmodes/rst
/usr/share/emacs25/site-lisp/flim/ntlm hides /usr/share/emacs/25.1/lisp/net/ntlm
/usr/share/emacs25/site-lisp/flim/hmac-md5 hides /usr/share/emacs/25.1/lisp/net/hmac-md5
/usr/share/emacs25/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/25.1/lisp/net/sasl-ntlm
/usr/share/emacs25/site-lisp/flim/sasl-digest hides /usr/share/emacs/25.1/lisp/net/sasl-digest
/usr/share/emacs25/site-lisp/flim/sasl hides /usr/share/emacs/25.1/lisp/net/sasl
/usr/share/emacs25/site-lisp/flim/sasl-cram hides /usr/share/emacs/25.1/lisp/net/sasl-cram
/usr/share/emacs25/site-lisp/flim/hmac-def hides /usr/share/emacs/25.1/lisp/net/hmac-def
Features:
(shadow emacsbug grep doc-view etags xref project tabify imenu man
latexenc log-edit easy-mmode pcvs-util add-log diff vc-cvs vc-dir ewoc
vc epa derived locate rect dired-aux eieio-opt speedbar sb-image ezimage
dframe find-func misearch multi-isearch dabbrev nero cl mailalias
time-stamp rmailout rmailkwd shr-color color server url-util shr dom
subr-x browse-url jka-compr parse-time unrmail bibtex info sh-script
executable sgml-mode cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs image-mode view conf-mode
generic vc-filewise vc-rcs octave smie longlines vc-dispatcher vc-svn
tex-mode compile qp rmailmm message mml mml-sec epg mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 desktop
frameset term/xterm xterm pot skeleton rmailsum rmail warnings sendmail
rfc2047 rfc2045 ietf-drums mail-utils mime-compose cal-china lunar solar
cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs vc-hg appt
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs tramp
tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete
format-spec bhl switch-to-shell openwith hi-lock xt-mouse ffap thingatpt
url-parse auth-source cl-seq eieio eieio-core cl-macs gnus-util
time-date mm-util help-fns mail-prsvr password-cache url-vars
scroll-in-place filladapt advice time quail mailcrypt rfc822 comint
ansi-color ring mailcrypt-init dired-x dired generic-x disp-table
finder-inf package epg-config seq byte-opt gv bytecomp byte-compile
cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib debian-el
debian-el-loaddefs w3m-load vm-autoload vm-autoloads vm-version vm-vars
vm-init mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)
Memory information:
((conses 16 552704 95748)
(symbols 48 37527 0)
(miscs 40 5169 2311)
(strings 32 83724 8222)
(string-bytes 1 2785896)
(vectors 16 61226)
(vector-slots 8 1717342 181831)
(floats 8 1054 991)
(intervals 56 47986 1943)
(buffers 976 126))
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-11-28 18:51 bug#25054: 25.1; bury-buffer makes bad choice of next buffer Francesco Potortì
@ 2016-11-28 19:14 ` martin rudalics
2016-11-28 20:32 ` Francesco Potortì
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2016-11-28 19:14 UTC (permalink / raw)
To: Francesco Potortì, 25054
> If I have the screen divided into two windows showing two different
> buffers and issue M-x bury-buffer on one of them, the window will show
> the same buffer that is shown in the other window.
>
> This is different from what it was in Emacs 22, and I find it very
> annoying. Unless there is good reason for the new behaviour, the buffer
> displayed should be the "other buffer". To reproduce:
>
> C-x 1 RET
> C-x b a RET
> C-x b b RET
> C-x b c RET
> C-x 4 b d RET
> M-x bury-buffer RET
>
> Now both windows show buffer c, while the current buffer should display
> buffer b.
Please try with ‘switch-to-visible-buffer’ customized to nil.
martin
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-11-28 19:14 ` martin rudalics
@ 2016-11-28 20:32 ` Francesco Potortì
2016-11-29 8:09 ` martin rudalics
0 siblings, 1 reply; 9+ messages in thread
From: Francesco Potortì @ 2016-11-28 20:32 UTC (permalink / raw)
To: martin rudalics; +Cc: 25054
> > If I have the screen divided into two windows showing two different
> > buffers and issue M-x bury-buffer on one of them, the window will show
> > the same buffer that is shown in the other window.
> >
> > This is different from what it was in Emacs 22, and I find it very
> > annoying. Unless there is good reason for the new behaviour, the buffer
> > displayed should be the "other buffer". To reproduce:
> >
> > C-x 1 RET
> > C-x b a RET
> > C-x b b RET
> > C-x b c RET
> > C-x 4 b d RET
> > M-x bury-buffer RET
> >
> > Now both windows show buffer c, while the current buffer should display
> > buffer b.
>
>Please try with ‘switch-to-visible-buffer’ customized to nil.
It works, thanks.
I wonder why the default was set to t. Do you know if there is a simple
explanation?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-11-28 20:32 ` Francesco Potortì
@ 2016-11-29 8:09 ` martin rudalics
2016-11-29 20:44 ` Francesco Potortì
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2016-11-29 8:09 UTC (permalink / raw)
To: Francesco Potortì; +Cc: 25054
> I wonder why the default was set to t. Do you know if there is a simple
> explanation?
To return to a previous window configuration without having to restore
it explicitly. Consider simultaneous editing of two portions of the
same buffer after C-x 2. If one of the windows is temporarily used for
showing things like help, info or completions, quitting that window
should implicitly restore previous buffer and location.
The thread on Bug#20861 contains an explanation why your buffer "c" (one
that was never shown before in the window you created via C-x 4 b) is
unveiled there by ‘bury-buffer’. Maybe Jürgen's solution could be
improved by switching to an already visible buffer (like "c") only after
all other possibilities have been exhausted. Patches welcome ;-)
martin
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-11-29 8:09 ` martin rudalics
@ 2016-11-29 20:44 ` Francesco Potortì
2016-11-30 7:53 ` martin rudalics
0 siblings, 1 reply; 9+ messages in thread
From: Francesco Potortì @ 2016-11-29 20:44 UTC (permalink / raw)
To: martin rudalics; +Cc: 25054
> > I wonder why the default was set to t. Do you know if there is a simple
> > explanation?
>
>To return to a previous window configuration without having to restore
>it explicitly. Consider simultaneous editing of two portions of the
>same buffer after C-x 2. If one of the windows is temporarily used for
>showing things like help, info or completions, quitting that window
>should implicitly restore previous buffer and location.
>
>The thread on Bug#20861 contains an explanation why your buffer "c" (one
>that was never shown before in the window you created via C-x 4 b) is
>unveiled there by ‘bury-buffer’. Maybe Jürgen's solution could be
>improved by switching to an already visible buffer (like "c") only after
>all other possibilities have been exhausted. Patches welcome ;-)
Ok, after setting switch-to-visible-buffer to nil it got better, but it
is not how it was with Emacs 22 (okay, I have emerged from a long time
tunnel).
My main problem is with the *mail* buffer (I have mail-user-agent set to
'sendmail-user-agent). After I send mail, the *mail* buffer is buried,
but after a while it pops up. I would expect that, being buried, it is
the last choice as the other buffer. Apparently it is not.
I don't know why, and I have not time to investigate now, sorry. But if
you care to suggest some ideas, I may find the time sooner or later :)
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-11-29 20:44 ` Francesco Potortì
@ 2016-11-30 7:53 ` martin rudalics
2016-12-06 11:48 ` Francesco Potortì
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2016-11-30 7:53 UTC (permalink / raw)
To: Francesco Potortì; +Cc: 25054
> My main problem is with the *mail* buffer (I have mail-user-agent set to
> 'sendmail-user-agent). After I send mail, the *mail* buffer is buried,
> but after a while it pops up. I would expect that, being buried, it is
> the last choice as the other buffer. Apparently it is not.
It is. But the "other buffer" is not necessarily the one that will be
shown in a window when that window's previous buffer is about getting
buried or killed.
> I don't know why, and I have not time to investigate now, sorry. But if
> you care to suggest some ideas, I may find the time sooner or later :)
I suppose you mean something like
(progn
(switch-to-buffer "a")
(switch-to-buffer "b")
(when (y-or-n-p "Bury b ? ")
(bury-buffer))
(while (y-or-n-p "Previous ? ")
(previous-buffer)))
The loop in this scenario will eventually switch to "b" (because it has
been already shown in the selected window) rather than to "*Messages*"
(simply because it has never shown up in that window before). We could
invent an option to change that behavior, but so far you would be its
only user. And it's not even clear to me how to formulate that option.
martin
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-11-30 7:53 ` martin rudalics
@ 2016-12-06 11:48 ` Francesco Potortì
2016-12-06 14:28 ` martin rudalics
0 siblings, 1 reply; 9+ messages in thread
From: Francesco Potortì @ 2016-12-06 11:48 UTC (permalink / raw)
To: martin rudalics; +Cc: 25054
> > My main problem is with the *mail* buffer (I have mail-user-agent set to
> > 'sendmail-user-agent). After I send mail, the *mail* buffer is buried,
> > but after a while it pops up. I would expect that, being buried, it is
> > the last choice as the other buffer. Apparently it is not.
>
>It is. But the "other buffer" is not necessarily the one that will be
>shown in a window when that window's previous buffer is about getting
>buried or killed.
...
>(progn
> (switch-to-buffer "a")
> (switch-to-buffer "b")
> (when (y-or-n-p "Bury b ? ")
> (bury-buffer))
> (while (y-or-n-p "Previous ? ")
> (previous-buffer)))
>
>The loop in this scenario will eventually switch to "b" (because it has
>been already shown in the selected window) rather than to "*Messages*"
>(simply because it has never shown up in that window before). We could
>invent an option to change that behavior, but so far you would be its
>only user. And it's not even clear to me how to formulate that option.
I see, thanks for the explanation.
I definitely do not like that behaviour. When I bury a buffer, I want
it to be the last choice for displaying a buffer in a window. It worked
like that in Emacs 22 and it was okay for me. I'd like to customise
that back. In Emacs 22, if I am not wrong that amounted to just advise
switch-to-buffer and changing buffer-name-history before executing the
original code. But by looking at the source code for switch-buffer in
buffer.c, it appears that wouldn't work any more.
Maybe I could write a piece of advise to switch-buffer or other-buffer
that plays with buffer predicates.
Or maybe I could try using the other_buffer_safely function in buffer.c
(but I don't know how to call it from elisp).
Can you suggest a way?
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-12-06 11:48 ` Francesco Potortì
@ 2016-12-06 14:28 ` martin rudalics
2022-01-29 16:35 ` Lars Ingebrigtsen
0 siblings, 1 reply; 9+ messages in thread
From: martin rudalics @ 2016-12-06 14:28 UTC (permalink / raw)
To: Francesco Potortì; +Cc: 25054
> Can you suggest a way?
Yes. We have two functions: ‘set-window-prev-buffers’ and
‘set-window-next-buffers’. Whenever you bury a buffer and an option
whose name you have to invent is non-nil, use these functions to remove
the buried buffer from these lists. Either for all windows or for the
selected window only - depending on whether you want to reserve two or
three values for the option.
martin
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#25054: 25.1; bury-buffer makes bad choice of next buffer
2016-12-06 14:28 ` martin rudalics
@ 2022-01-29 16:35 ` Lars Ingebrigtsen
0 siblings, 0 replies; 9+ messages in thread
From: Lars Ingebrigtsen @ 2022-01-29 16:35 UTC (permalink / raw)
To: martin rudalics; +Cc: 25054
martin rudalics <rudalics@gmx.at> writes:
>> Can you suggest a way?
>
> Yes. We have two functions: ‘set-window-prev-buffers’ and
> ‘set-window-next-buffers’. Whenever you bury a buffer and an option
> whose name you have to invent is non-nil, use these functions to remove
> the buried buffer from these lists. Either for all windows or for the
> selected window only - depending on whether you want to reserve two or
> three values for the option.
Skimming this thread, it seems like Emacs is working as designed, and
has the required options to allow customising the actions according to
how the user wants them to work, so I'm closing this bug report. (If I
misunderstood and there's something that should be fixed here, please
respond to the debbugs address and we'll reopen.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-01-29 16:35 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-28 18:51 bug#25054: 25.1; bury-buffer makes bad choice of next buffer Francesco Potortì
2016-11-28 19:14 ` martin rudalics
2016-11-28 20:32 ` Francesco Potortì
2016-11-29 8:09 ` martin rudalics
2016-11-29 20:44 ` Francesco Potortì
2016-11-30 7:53 ` martin rudalics
2016-12-06 11:48 ` Francesco Potortì
2016-12-06 14:28 ` martin rudalics
2022-01-29 16:35 ` Lars Ingebrigtsen
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).