GNU bug report logs - #64398
Bump buffers-menu-max-size value

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64398 in the body.
You can then email your comments to 64398 AT debbugs.gnu.org in the normal way.

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

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

From: Angelo Borsotti <angelo.borsotti <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Buffer list
Date: Sat, 1 Jul 2023 12:31:37 +0200

[Message part 1 (text/plain, inline)]

Message-ID: <83wmzj6i1g.fsf <at> ANGELO-PC.mail-host-address-is-not-set>
--text follows this line--

This is not really a bug, rather a feature request.
The list of buffers, displayed by clicking on "Buffers" in the top bar,
displays only 10 buffers, forcing the user in too many cases to display
all of them to find the desired one. Would it be possible to double the
length of the list displayed?

Thank you
-Angelo Borsotti


In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.3086)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Fundamental

Minor modes in effect:
  global-hl-line-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc rfc822 mml mml-sec epa
derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail misearch multi-isearch
dired-aux dired dired-loaddefs mhtml-mode css-mode smie eww xdg
url-queue shr kinsoku svg xml browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf mailcap puny
mm-url gnus nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045
ietf-drums text-property-search mail-utils wid-edit mm-util mail-prsvr
color js imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs sgml-mode facemenu dom cus-start
thingatpt ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help
ediff-init ediff-util time-date vc-git diff-mode easy-mmode
vc-dispatcher url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json subr-x map seq byte-opt gv
bytecomp byte-compile cconv url-vars hl-line edt picture ehelp edmacro
kmacro cl-loaddefs cl-lib delsel cua-base cus-load iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer 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 composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 227301 48697)
 (symbols 48 14917 4)
 (strings 32 56518 4335)
 (string-bytes 1 2270655)
 (vectors 16 51541)
 (vector-slots 8 1638125 33158)
 (floats 8 714 520)
 (intervals 56 2105 1107)
 (buffers 992 54))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Angelo Borsotti <angelo.borsotti <at> gmail.com>
Cc: 64398 <at> debbugs.gnu.org
Subject: Re: bug#64398: Buffer list
Date: Sat, 01 Jul 2023 13:44:09 +0300

> From: Angelo Borsotti <angelo.borsotti <at> gmail.com>
> Date: Sat, 1 Jul 2023 12:31:37 +0200
> 
> This is not really a bug, rather a feature request.
> The list of buffers, displayed by clicking on "Buffers" in the top bar,
> displays only 10 buffers, forcing the user in too many cases to display
> all of them to find the desired one. Would it be possible to double the
> length of the list displayed?

You can do it yourself by customizing the value of the variable
buffers-menu-max-size to something greater than 10, its current
default.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64398 <at> debbugs.gnu.org, Angelo Borsotti <angelo.borsotti <at> gmail.com>
Subject: Re: bug#64398: Buffer list
Date: Mon, 4 Sep 2023 13:22:04 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Angelo Borsotti <angelo.borsotti <at> gmail.com>
>> Date: Sat, 1 Jul 2023 12:31:37 +0200
>>
>> This is not really a bug, rather a feature request.
>> The list of buffers, displayed by clicking on "Buffers" in the top bar,
>> displays only 10 buffers, forcing the user in too many cases to display
>> all of them to find the desired one. Would it be possible to double the
>> length of the list displayed?
>
> You can do it yourself by customizing the value of the variable
> buffers-menu-max-size to something greater than 10, its current
> default.

I see that the current default was chosen in 1993 (commit 4095411173af).
Perhaps 30 years is long enough that it's time to update it.  Screen
sizes are much larger these days, after all.

Are there any adverse effects associated with, say, setting it to 15 or
even doubling the number?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Tue, 05 Sep 2023 05:30:35 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 4 Sep 2023 13:22:04 -0700
> Cc: Angelo Borsotti <angelo.borsotti <at> gmail.com>, 64398 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Angelo Borsotti <angelo.borsotti <at> gmail.com>
> >> Date: Sat, 1 Jul 2023 12:31:37 +0200
> >>
> >> This is not really a bug, rather a feature request.
> >> The list of buffers, displayed by clicking on "Buffers" in the top bar,
> >> displays only 10 buffers, forcing the user in too many cases to display
> >> all of them to find the desired one. Would it be possible to double the
> >> length of the list displayed?
> >
> > You can do it yourself by customizing the value of the variable
> > buffers-menu-max-size to something greater than 10, its current
> > default.
> 
> I see that the current default was chosen in 1993 (commit 4095411173af).
> Perhaps 30 years is long enough that it's time to update it.  Screen
> sizes are much larger these days, after all.
> 
> Are there any adverse effects associated with, say, setting it to 15 or
> even doubling the number?

If we make the number much larger, we should probably have a separate
default value for TTY frames, where I think small frame sizes are
still quite frequent.

Or maybe we should have the default computed dynamically based on the
actual frame size?

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Tue, 5 Sep 2023 14:46:32 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

> If we make the number much larger, we should probably have a separate
> default value for TTY frames, where I think small frame sizes are
> still quite frequent.

Agreed.

> Or maybe we should have the default computed dynamically based on the
> actual frame size?

That's an interesting idea, but would be more work, and we have other
things to do too.  It also somehow seems to be the job of the toolkit to
worry about such things, but maybe that's just me.

It's tempting to just bump this to some similarly conservative value
like 15 or 12 on graphical displays, and be done with it.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Wed, 06 Sep 2023 14:25:11 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 5 Sep 2023 14:46:32 -0700
> Cc: angelo.borsotti <at> gmail.com, 64398 <at> debbugs.gnu.org
> 
> It's tempting to just bump this to some similarly conservative value
> like 15 or 12 on graphical displays, and be done with it.

We could do that, but then 15 is the maximum value we could use, since
it makes the menu take 24 lines, which is the largest value possible
with 24-line TTY frames.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Wed, 6 Sep 2023 04:54:39 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> It's tempting to just bump this to some similarly conservative value
>> like 15 or 12 on graphical displays, and be done with it.
>
> We could do that, but then 15 is the maximum value we could use, since
> it makes the menu take 24 lines, which is the largest value possible
> with 24-line TTY frames.

How about something like the below?

diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
index 5e837485db3..14d8d664d58 100644
--- a/lisp/menu-bar.el
+++ b/lisp/menu-bar.el
@@ -2314,14 +2314,16 @@ menu-bar-select-yank
 
 ;;; Buffers Menu

-(defcustom buffers-menu-max-size 10
+(defcustom buffers-menu-max-size (if (display-graphic-p) 15 10)
   "Maximum number of entries which may appear on the Buffers menu.
-If this is 10, then only the ten most-recently-selected buffers are shown.
-If this is nil, then all buffers are shown.
-A large number or nil slows down menu responsiveness."
-  :type '(choice integer
-		 (const :tag "All" nil))
-  :group 'menu)
+If this is a number, only that many most-recently-selected
+buffers are shown.
+If this is nil, all buffers are shown."
+  :type '(choice natnump
+                 (const :tag "All" nil))
+  :group 'menu
+  :version "30.1")

 (defcustom buffers-menu-buffer-name-length 30
   "Maximum length of the buffer name on the Buffers menu.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Wed, 06 Sep 2023 15:39:06 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Wed, 6 Sep 2023 04:54:39 -0700
> Cc: angelo.borsotti <at> gmail.com, 64398 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> It's tempting to just bump this to some similarly conservative value
> >> like 15 or 12 on graphical displays, and be done with it.
> >
> > We could do that, but then 15 is the maximum value we could use, since
> > it makes the menu take 24 lines, which is the largest value possible
> > with 24-line TTY frames.
> 
> How about something like the below?

menu-bar.el is preloaded, so we should use custom-initialize-delay, I
think?

Otherwise LGTM, thanks.

Message #33 received at 64398-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 64398-done <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Sat, 30 Sep 2023 16:09:36 -0700

Version: 30.1

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Wed, 6 Sep 2023 04:54:39 -0700
>> Cc: angelo.borsotti <at> gmail.com, 64398 <at> debbugs.gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> It's tempting to just bump this to some similarly conservative value
>> >> like 15 or 12 on graphical displays, and be done with it.
>> >
>> > We could do that, but then 15 is the maximum value we could use, since
>> > it makes the menu take 24 lines, which is the largest value possible
>> > with 24-line TTY frames.
>>
>> How about something like the below?
>
> menu-bar.el is preloaded, so we should use custom-initialize-delay, I
> think?

Right.

> Otherwise LGTM, thanks.

Thanks, installed on master

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 64398 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Thu, 05 Oct 2023 15:21:05 +0800

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> It's tempting to just bump this to some similarly conservative value
>>> like 15 or 12 on graphical displays, and be done with it.
>>
>> We could do that, but then 15 is the maximum value we could use, since
>> it makes the menu take 24 lines, which is the largest value possible
>> with 24-line TTY frames.
>
> How about something like the below?
>
> diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
> index 5e837485db3..14d8d664d58 100644
> --- a/lisp/menu-bar.el
> +++ b/lisp/menu-bar.el
> @@ -2314,14 +2314,16 @@ menu-bar-select-yank
>  
>  ;;; Buffers Menu
>
> -(defcustom buffers-menu-max-size 10
> +(defcustom buffers-menu-max-size (if (display-graphic-p) 15 10)
>    "Maximum number of entries which may appear on the Buffers menu.
> -If this is 10, then only the ten most-recently-selected buffers are shown.
> -If this is nil, then all buffers are shown.
> -A large number or nil slows down menu responsiveness."
> -  :type '(choice integer
> -		 (const :tag "All" nil))
> -  :group 'menu)
> +If this is a number, only that many most-recently-selected
> +buffers are shown.
> +If this is nil, all buffers are shown."
> +  :type '(choice natnump
> +                 (const :tag "All" nil))
> +  :group 'menu
> +  :version "30.1")
>
>  (defcustom buffers-menu-buffer-name-length 30
>    "Maximum length of the buffer name on the Buffers menu.

This doesn't work because menu-bar.el is preloaded and additionally
because Emacs supports creating both GUI and terminal frames in the same
process, whereas a feature can only be loaded once, with the value of
display-graphic-p subject to whatever frame is selected at the time it
is loaded.  Why not set it to 15 and call it a day?

TIA.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 64398 <at> debbugs.gnu.org, stefankangas <at> gmail.com, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Thu, 05 Oct 2023 11:10:21 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  64398 <at> debbugs.gnu.org,
>   angelo.borsotti <at> gmail.com
> Date: Thu, 05 Oct 2023 15:21:05 +0800
> 
> Stefan Kangas <stefankangas <at> gmail.com> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> It's tempting to just bump this to some similarly conservative value
> >>> like 15 or 12 on graphical displays, and be done with it.
> >>
> >> We could do that, but then 15 is the maximum value we could use, since
> >> it makes the menu take 24 lines, which is the largest value possible
> >> with 24-line TTY frames.
> >
> > How about something like the below?
> >
> > diff --git a/lisp/menu-bar.el b/lisp/menu-bar.el
> > index 5e837485db3..14d8d664d58 100644
> > --- a/lisp/menu-bar.el
> > +++ b/lisp/menu-bar.el
> > @@ -2314,14 +2314,16 @@ menu-bar-select-yank
> >  
> >  ;;; Buffers Menu
> >
> > -(defcustom buffers-menu-max-size 10
> > +(defcustom buffers-menu-max-size (if (display-graphic-p) 15 10)
> >    "Maximum number of entries which may appear on the Buffers menu.
> > -If this is 10, then only the ten most-recently-selected buffers are shown.
> > -If this is nil, then all buffers are shown.
> > -A large number or nil slows down menu responsiveness."
> > -  :type '(choice integer
> > -		 (const :tag "All" nil))
> > -  :group 'menu)
> > +If this is a number, only that many most-recently-selected
> > +buffers are shown.
> > +If this is nil, all buffers are shown."
> > +  :type '(choice natnump
> > +                 (const :tag "All" nil))
> > +  :group 'menu
> > +  :version "30.1")
> >
> >  (defcustom buffers-menu-buffer-name-length 30
> >    "Maximum length of the buffer name on the Buffers menu.
> 
> This doesn't work because menu-bar.el is preloaded and additionally
> because Emacs supports creating both GUI and terminal frames in the same
> process, whereas a feature can only be loaded once, with the value of
> display-graphic-p subject to whatever frame is selected at the time it
> is loaded.  Why not set it to 15 and call it a day?

It's possible, but then we will not be able to extend this in the
future anymore, as I explained above.  But maybe we don't care.

If we do care, then we could have an additional option, or we could
make this option accept a cons cell, or something else.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Thu, 5 Oct 2023 12:54:02 +0000

reopen 64398
retitle 64398 Bump buffers-menu-max-size value
thanks

Eli Zaretskii <eliz <at> gnu.org> writes:

>> This doesn't work because menu-bar.el is preloaded and additionally
>> because Emacs supports creating both GUI and terminal frames in the same
>> process, whereas a feature can only be loaded once, with the value of
>> display-graphic-p subject to whatever frame is selected at the time it
>> is loaded.  Why not set it to 15 and call it a day?
>
> It's possible, but then we will not be able to extend this in the
> future anymore, as I explained above.  But maybe we don't care.
>
> If we do care, then we could have an additional option, or we could
> make this option accept a cons cell, or something else.

If we know that it will work, perhaps the simplest solution here is
fine, and we can just bump the default to 15 unconditionally.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: luangruo <at> yahoo.com, 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Thu, 05 Oct 2023 19:05:31 +0300

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 5 Oct 2023 12:54:02 +0000
> Cc: 64398 <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> This doesn't work because menu-bar.el is preloaded and additionally
> >> because Emacs supports creating both GUI and terminal frames in the same
> >> process, whereas a feature can only be loaded once, with the value of
> >> display-graphic-p subject to whatever frame is selected at the time it
> >> is loaded.  Why not set it to 15 and call it a day?
> >
> > It's possible, but then we will not be able to extend this in the
> > future anymore, as I explained above.  But maybe we don't care.
> >
> > If we do care, then we could have an additional option, or we could
> > make this option accept a cons cell, or something else.
> 
> If we know that it will work, perhaps the simplest solution here is
> fine, and we can just bump the default to 15 unconditionally.

Fine, let's go by that for now, and revisit it if and when it becomes
an issue.  But please add a comment there saying that going much
further than 15 should consider the height of TTY frames.

Message #54 received at 64398-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 64398-done <at> debbugs.gnu.org, angelo.borsotti <at> gmail.com
Subject: Re: bug#64398: Buffer list
Date: Thu, 5 Oct 2023 18:19:23 +0000

Version: 30.1

Eli Zaretskii <eliz <at> gnu.org> writes:

>> If we know that it will work, perhaps the simplest solution here is
>> fine, and we can just bump the default to 15 unconditionally.
>
> Fine, let's go by that for now, and revisit it if and when it becomes
> an issue.  But please add a comment there saying that going much
> further than 15 should consider the height of TTY frames.

Now done on master.

[1: eb5a453a58a]: 2023-10-05 20:17:53 +0200
  Set buffers-menu-max-size to 15 unconditionally
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=eb5a453a58a4d7fe1ab213d0fdb746ccb65b9909

Previous Next

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