buff-menu.el changes

buff-menu.el changes

[Robert J. Chassell]

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

Re: buff-menu.el changes

[Juanma Barranquero]

On Mon, 16 Dec 2002 15:04:57 -0500 (EST)
"Robert J. Chassell" <bob@rattlesnake.com> wrote:

> Changes were made in    lisp/buff-menu.el

>     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.
[...]
>     In any event, please place the second line of the header, the
>     underlines, close to the value for the first line of the header.
[...]
>     Please define the second line of the header as the second line of
>     the Buffer-menu-header-line-format variable.
[...]
>     Please fix this, since this makes a plain vanilla instance of
>     Emacs look ugly and ill designed.

I´ve installed today's changes to lisp/buff-menu.el (because I've been
instructed to do so) but I don't know/understand the code and don't know
if the author is reading the list, so I suggest you should make the
changes you feel approppriate...

-- 
Juanma Barranquero <lektu@terra.es>

Re: buff-menu.el changes

[Daniel Pfeiffer]

"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/ --

Re: buff-menu.el changes

[Miles Bader]

Daniel Pfeiffer <occitan@esperanto.org> writes:
> Being able to move over intangible text charwise but not linewise sounds
> counterintuitive and would seem a 21.3 bug.

Almost certainly; the `line-move' function is chock full of special
code to deal with intangible characters, which in my experience breaks
often, and never _really_ works correctly.  I don't really understand
the it that well, but I think the problem often involves hidden
newline characters.

If anyone's interested, here's a simple test-case that illustrates the
problem:

   (with-current-buffer (get-buffer-create "*test*")
     (insert "1: hello\n")
     (insert (propertize "2: cruel\n" 'invisible t 'intangible t))
     (insert "3: world\n")
     (insert "4:\n"))

After evaluating that, go to the *test* buffer, and move around using
C-n & C-p.  I can see the following bugs:

  (1) If the cursor is in the first column, you can't move from line
      "3:" to line "4:" using C-n (but C-p works all the way from the
      end of the buffer to the beginning).

  (2) If the cursor is in a different column, C-n seems to work
      correctly on all lines, but C-p won't move from line "3:" to
      line "1:" (it seems to work on all other line though).

-Miles
-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

intangible characters bugs [was Re: buff-menu.el changes]

[Robert J. Chassell]

Today's CVS snapshot of Tue, 2002 Dec 17 16:51 UTC
GNU Emacs 21.3.50.27 (i686-pc-linux-gnu, X toolkit)
(but with Miles' patch to src/xfaces.c applied to that file)
started with

     /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'


   next-line (C-n) works for me, even with 21.2 -q.  It simply skips
   the intangible line.

This is a bug in 21.3.  Miles Bader <miles@lsi.nec.co.jp> sent a
test-case.  I can confirm that the current CVS snapshot has the same
problems as he describes.  I cannot fix this.


    ... here's a simple test-case that illustrates the
    problem:

       (with-current-buffer (get-buffer-create "*test*")
         (insert "1: hello\n")
         (insert (propertize "2: cruel\n" 'invisible t 'intangible t))
         (insert "3: world\n")
         (insert "4:\n"))

    After evaluating that, go to the *test* buffer, and move around
    using C-n & C-p.  I can see the following bugs:

      (1) If the cursor is in the first column, you can't move from
          line "3:" to line "4:" using C-n (but C-p works all the way
          from the end of the buffer to the beginning).

      (2) If the cursor is in a different column, C-n seems to work
          correctly on all lines, but C-p won't move from line "3:" to
          line "1:" (it seems to work on all other line though).

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: buff-menu.el changes

[Robert J. Chassell]

   Changes were made in    lisp/buff-menu.el

I lack the time to change buff-menu.el, except for changing the
default widths for Buffer-menu-buffer+size-width and 
Buffer-menu-mode-width, which I have done.

As for the others:

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

This is the result of a bug in handling intangible text.  Miles Bader
<miles@lsi.nec.co.jp> has produced a good, short test-case.

I don't know how to handle intangible text.  Please someone fix this!
The bug effects more than the `list-buffers' command.

     * Second, the addition of the `C' to the existing `RM' is consistent
       logically, ....   [but] The new heading format with the
       `C' is hard coded into list-buffers-noselect.

A new variable is needed, `Buffer-menu-header-first-line', so people
can change this.  (The variable need not be customizeable; only a few
people will want to make the change.)  Then, from this, a function
should create `Buffer-menu-header-second-line' based on the lengths of
the elements of the first line.  One problem will be that the
`Buffer-menu-buffer+size' function needs to be called every time that
the `list-buffers-noselect' function is called.  I think the best way
to go is to rewrite `Buffer-menu-buffer+size'.

     * Third, the default width for Buffer-menu-buffer+size-width is 21,
       but I find that 24 makes a better default.

I have changed these defaults.


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

I think you forgot to include the left hand fringe width and assumed a
value for the scroll-bar-width which does not apply to all instances
of Emacs started as:

    emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

(Perhaps screen resolution has something to do with it.  My
high-quality screen has a resolution of 135 pixels per inch; my other
monitors have a resolution of 72 pixels per inch.)

You can determine the left hand fringe width in pixels with the
expression:

   (frame-parameter nil 'left-fringe)

(I think.)  You will need to convert this to column-widths, assuming
that `list-buffers' sticks to fixed width fonts.  I think I have seen
a way to make this conversion but cannot remember where.

At the same time, you need to compute the actual scroll-bar-width.
Even when I turn off fringes in my plain vanilla Emacs, the header
line is not above the text as it should be.  I don't know how to handle
scroll-bar-width.

Best wishes.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com