unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

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