[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: buff-menu.el changes
From: |
Daniel Pfeiffer |
Subject: |
Re: buff-menu.el changes |
Date: |
Tue, 17 Dec 2002 00:00:15 +0100 |
"Robert J. Chassell" <address@hidden> skribis:
> 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.
next-line (C-n) works for me, even with 21.2 -q. It simply skips the
intangible line.
> Instead, you must use forward-char (C-f) to go to the next line.
Being able to move over intangible text charwise but not linewise sounds
counterintuitive and would seem a 21.3 bug. Also a bug is being able to go
before the C. I even tried (in 21.2) to add another intangible space before
the C and to narrow it away. Even then I could go before the C, i.e. between
two chars with the same ingtangible value.
> 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.
Actually I made the two styles of header optional because Info does it that
way. But I can't see who would not want to use the much neater new format. It
would make the code simpler to use only the new-style fixed header.
> * 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.
I don't like columns with stuff in them but without a header, but feel free to
make it optional.
> 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.
That's because of the two different kinds of header line as I mentioned above.
If I insert it, I left it at the beginning, where it used to be done. But when
I set it in the new variable, it must be done at the end, because local
variables get cleared.
> Please define the second line of the header as the second line of
> the Buffer-menu-header-line-format variable.
I don't like columns with stuff in them but without a header, but feel free to
make it optional.
> * 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.
I stuck to the old widths designed for 80 columns. Of course I added the
clipping because everything was so cluttered and columns so irregular as to
make the whole thing useless. The change is trivial, feel free to do it.
> * 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.
My columns were designed to align nicely. Do different Emacsen have different
widths of the gray continuation-line indicator columns? Mine are 1 space wide,
even with -q. Please correct it, as I don't know how this works.
coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn
Daniel Pfeiffer
-- GPL 3: take the wind out of Palladium's sails! --
------
-- My other stuff here too, sawfish, make.pl...: --
------
-- http://dapfy.bei.t-online.de/ --