Re: buff-menu.el changes

[Daniel Pfeiffer <occitan@esperanto.org>]

"Robert J. Chassell" <bob@rattlesnake.com> 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/ --