From: "Robert J. Chassell" <bob@rattlesnake.com>
Cc: bob@rattlesnake.com
Subject: buff-menu.el changes
Date: Mon, 16 Dec 2002 15:04:57 -0500 (EST) [thread overview]
Message-ID: <m18O1U1-000IeAC@localhost> (raw)
Today's CVS snapshot, Mon, 2002 Dec 16 18:58 UTC
GNU Emacs 21.3.50.23 (i686-pc-linux-gnu, X toolkit)
Changes were made in lisp/buff-menu.el
* First, when Buffer-menu-use-header-line is nil it is impossible to
move to the next line using the next-line (C-n) command when point
is on the `C' of CRM, which is the first character of the first
line of a buffer.
Instead, you must use forward-char (C-f) to go to the next line.
Obviously, the intent is that no one go to that first character in
the buffer. However, for whatever reason, I find myself there
frequently, so this decreases the value of the user interface.
The problem can be solved by commenting out the line
(put-text-property 1 (point) 'intangible t)
in the function definition for list-buffers-noselect
Please either remove that line or, if you think that some people
will like the feature, make it a variable that leaves the user
free to move by default using the standard command.
* Second, the addition of the `C' to the existing `RM' is consistent
logically, since it must mean `current', but it is not needed and
makes the headline look `heavy'.
Th new heading format with the `C' is hard coded into
list-buffers-noselect. Please either revert the hard coding
or make the format of a header line be a variable, such as
Buffer-menu-header-line-format
In any event, please place the second line of the header, the
underlines, close to the value for the first line of the header.
As written, the first line of the header is in the let statement,
but the second line of the header is in the body of the defun.
This separation of the two header lines not only makes the defun
hard to maintain, but is ugly.
Please define the second line of the header as the second line of
the Buffer-menu-header-line-format variable.
* Third, the default width for Buffer-menu-buffer+size-width is 21,
but I find that 24 makes a better default.
Similarly, the default width for Buffer-menu-buffer+size-width is
11, but I find that 16 makes a better default.
With the larger defaults, Mode names such as that for *scratch*
Lisp Interaction
are not reduced to
Lisp Intera
as they now are in a plain vanilla Emacs started with `-q'.
Likewise, the entry for the man page for resolv.conf looks like
with the bigger values:
% *Man resolv.conf* 5194 Man
but with the current default, that entry looks like this:
% *Man resolv.con: 5194 Man
Both the cut-off entries look ugly. The entry for *scratch*
occurs by default, since Emacs always creates a *scratch* buffer.
So that entry should look good.
* Fourth, when Buffer-menu-use-header-line is t, the `CRM'
characters in the header line do not line up above their
respective `Current', `Read-only', and `Modified' columns.
In a plain vanilla GNU Emacs, started with `-q', the `M' is over
the . that indicates the current buffer.
Please fix this, since this makes a plain vanilla instance of
Emacs look ugly and ill designed.
Thank you.
--
Robert J. Chassell Rattlesnake Enterprises
http://www.rattlesnake.com GnuPG Key ID: 004B4AC8
http://www.teak.cc bob@rattlesnake.com
next reply other threads:[~2002-12-16 20:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-16 20:04 Robert J. Chassell [this message]
2002-12-16 21:05 ` buff-menu.el changes Juanma Barranquero
2002-12-16 23:00 ` Daniel Pfeiffer
2002-12-17 1:30 ` Miles Bader
2002-12-17 17:00 ` intangible characters bugs [was Re: buff-menu.el changes] Robert J. Chassell
2002-12-18 20:40 ` buff-menu.el changes Robert J. Chassell
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=m18O1U1-000IeAC@localhost \
--to=bob@rattlesnake.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).