From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: 64398@debbugs.gnu.org, angelo.borsotti@gmail.com
Subject: bug#64398: Buffer list
Date: Tue, 05 Sep 2023 05:30:35 +0300 [thread overview]
Message-ID: <83sf7t4aic.fsf@gnu.org> (raw)
In-Reply-To: <CADwFkm=vAbNJSxMC6c-3ETHyYCrCjp2DZJGucAR1Naer3iQHhg@mail.gmail.com> (message from Stefan Kangas on Mon, 4 Sep 2023 13:22:04 -0700)
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 4 Sep 2023 13:22:04 -0700
> Cc: Angelo Borsotti <angelo.borsotti@gmail.com>, 64398@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> From: Angelo Borsotti <angelo.borsotti@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?
next prev parent reply other threads:[~2023-09-05 2:30 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-01 10:31 bug#64398: Buffer list Angelo Borsotti
2023-07-01 10:44 ` Eli Zaretskii
2023-09-04 20:22 ` Stefan Kangas
2023-09-05 2:30 ` Eli Zaretskii [this message]
2023-09-05 21:46 ` Stefan Kangas
2023-09-06 11:25 ` Eli Zaretskii
2023-09-06 11:54 ` Stefan Kangas
2023-09-06 12:39 ` Eli Zaretskii
2023-09-30 23:09 ` Stefan Kangas
2023-10-05 7:21 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-05 8:10 ` Eli Zaretskii
2023-10-05 12:54 ` Stefan Kangas
2023-10-05 16:05 ` Eli Zaretskii
2023-10-05 18:19 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83sf7t4aic.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=64398@debbugs.gnu.org \
--cc=angelo.borsotti@gmail.com \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).