buff-menu.el header line

buff-menu.el header line

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Thu, 2004 Nov 18  15:43 UTC
GNU Emacs 21.3.50.9 (i686-pc-linux-gnu, GTK+ Version 2.4.13)
started with

    /usr/local/src/emacs/src/emacs -Q

When `Buffer-menu-use-header-line' is nil, the header line generated
by `list-buffers' fails to line up with the underlines.  (The default
is that `Buffer-menu-use-header-line' is t.)

The misalignment can be fixed by deleting the space before the `CRM'
in `list-buffers-noselect' on line 648 of emacs/lisp/buff-menu.el

Change
	 (header (concat " " (propertize "CRM " 'face 'fixed-pitch)
to
	 (header (concat (propertize "CRM " 'face 'fixed-pitch)

Also, the header line has two different height faces.  The difference
is small, but can be seen.

The `C' of `CRM' uses

    -Adobe-Courier-Medium-R-Normal--17-120-100-100-M-100-ISO8859-1 (0x43)

and the `B' of `Buffer' uses

    -ETL-Fixed-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1 (0x42)

I determined this by commenting out line 674 of
`list-buffers-noselect' in emacs/lisp/buff-menu.el

;;	(put-text-property 1 (point) 'intangible t)
        )

Do others see the same problems as I?  (I don't know for sure whether
the issues result from my display or are general.)

If others see the same problems, then 

 1. I expect no argument over deleting the extraneous white space on
    line 648.

 2. The issue of different sized faces is one of sensitivity and
    practicality.  I do not have any same-sized faces with the same
    looks.  The faces chosen have the closest size.

    The problem does not appear to occur when
    `Buffer-menu-use-header-line' is set to t, the default.  I suspect
    most people use the default.  Perhaps nothing should be done.

 3. There may be more argument about deleting the line providing an
    intangible text property.  I always comment it out because its
    existence means I cannot use `C-n' (next-line) when point is in
    the header.  On the other hand, others may prefer only to use
    `C-f' (forward-char), which leaves the header line and its
    underlining.

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

RE: buff-menu.el header line

[Drew Adams]

    When `Buffer-menu-use-header-line' is nil, the header line generated
    by `list-buffers' fails to line up with the underlines.

Right. I reported the same bug on 10/16:

1. The column headings have mouse-face highlighting, and they should
   sort the columns when you click them, but they don't. Instead, you
   get this error: No buffer on this line. The key sequence of mouse-2
   on a column heading is bound to `Buffer-menu-mouse-select'.

2. The second line in the buffer is used to underline (with "---") the
   column headings of the first line, but the underlinings don't line
   up with the column headings. The first line (headings) starts with
   a space, but it should not. The first line does not line up with any of
   the other lines.

  - Drew

Re: buff-menu.el header line

[Robert J. Chassell]

       When `Buffer-menu-use-header-line' is nil, the header line generated
       by `list-buffers' fails to line up with the underlines.

   Right. 

Also

    ... The column headings have mouse-face highlighting, and they
    should sort the columns when you click them, but they
    don't. Instead, you get this error: No buffer on this line. The
    key sequence of mouse-2 on a column heading is bound to
    `Buffer-menu-mouse-select'.

Good point!  I just tried the same and it failed.  (I had never tried
sorting before.)

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

Re: buff-menu.el header line

[Stefan Monnier]

>  1. I expect no argument over deleting the extraneous white space on
>     line 648.

IIRC removing the whitespace breaks alignment if you use a header-line in
a window-system (i.e. what I expect to be the default case).

>  3. There may be more argument about deleting the line providing an
>     intangible text property.  I always comment it out because its
>     existence means I cannot use `C-n' (next-line) when point is in
>     the header.  On the other hand, others may prefer only to use
>     `C-f' (forward-char), which leaves the header line and its
>     underlining.

I don't particularly like `intangible', but the above suggests that a better
solution is to fix C-n.


        Stefan

Re: buff-menu.el header line

[Robert J. Chassell]

    IIRC removing the whitespace breaks alignment if you use a
    header-line in a window-system (i.e. what I expect to be the
    default case).

What do you mean by a `window-system'?  I just tried both `emacs -Q'
in X Windows and `emacs -Q -nw' in an xterm in that Windows, both
using the buffer-menu.el with the changes I put in and with
`Buffer-menu-use-header-line' nil, and both worked fine.

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

Re: buff-menu.el header line

[Stefan Monnier]

>     IIRC removing the whitespace breaks alignment if you use a
>     header-line in a window-system (i.e. what I expect to be the
>     default case).

> What do you mean by a `window-system'?  I just tried both `emacs -Q'
> in X Windows and `emacs -Q -nw' in an xterm in that Windows, both
> using the buffer-menu.el with the changes I put in and with
> `Buffer-menu-use-header-line' nil, and both worked fine.

I said "if you use a header-line", i.e. with Buffer-menu-use-header-line set
to t.  In my case the lack of leading space causes the CRM to not be aligned
(it doesn't leave space for the scrollbar and the left fringe).

Can you try the patch below instead of your "remove the leading space"?


        Stefan


* auto-adding monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-97 to greedy revision library /part/00/Tmp/monnier/archlib
* found immediate ancestor revision in library (monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-96)
* patching for this revision (monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-97)
--- orig/lisp/buff-menu.el
+++ mod/lisp/buff-menu.el
@@ -653,7 +653,7 @@
 			 (Buffer-menu-make-sort-button "Mode" 4) mode-end
 			 (Buffer-menu-make-sort-button "File" 5) "\n"))
 	 list desired-point)
-    (when Buffer-menu-use-header-line
+    ;; (when Buffer-menu-use-header-line
       (let ((pos 0))
 	;; Turn spaces in the header into stretch specs so they work
 	;; regardless of the header-line face.
@@ -662,7 +662,7 @@
 	  (put-text-property (match-beginning 0) pos 'display
 			     ;; Assume fixed-size chars
 			     (list 'space :align-to (1- pos))
-			     header))))
+			     header)));; )
     (with-current-buffer (get-buffer-create "*Buffer List*")
       (setq buffer-read-only nil)
       (erase-buffer)

Re: buff-menu.el header line

[Robert J. Chassell]

   I said "if you use a header-line", i.e. with Buffer-menu-use-header-line set
   to t.  In my case the lack of leading space causes the CRM to not be aligned
   (it doesn't leave space for the scrollbar and the left fringe).

   Can you try the patch below instead of your "remove the leading space"?

Ah!  Thank you.  Now I understand.  The patch seems to work!  I will
have to test it more (tomorrow) but this looks like a solution to one
of the issues.

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

Re: buff-menu.el header line

[Robert J. Chassell]

Your fixes (revision 1.73) to patch list-buffers-noselect to fit in 80
columns work OK for me.

As for the alignment patch, it works using today's CVS checkout of 
Fri, 2004 Nov 19  14:13 UTC, rebuilt with `bootfast'.

However, the intangible text property still needs to be changed.  
Converting that line to 

	(put-text-property 1 (point) 'fixed-pitch t))

looks OK to me.

Here are the two patches to your revision 1.73:


diff -rc2P /usr/local/src/emacs/lisp/buff-menu.el.\~1.73.\~ /usr/local/src/emacs/lisp/buff-menu.el
*** /usr/local/src/emacs/lisp/buff-menu.el.~1.73.~	Fri Nov 19 14:13:41 2004
--- /usr/local/src/emacs/lisp/buff-menu.el	Fri Nov 19 15:05:29 2004
***************
*** 654,658 ****
  			 (Buffer-menu-make-sort-button "File" 5) "\n"))
  	 list desired-point)
!     (when Buffer-menu-use-header-line
        (let ((pos 0))
  	;; Turn spaces in the header into stretch specs so they work
--- 654,658 ----
  			 (Buffer-menu-make-sort-button "File" 5) "\n"))
  	 list desired-point)
! ;;    (when Buffer-menu-use-header-line
        (let ((pos 0))
  	;; Turn spaces in the header into stretch specs so they work
***************
*** 663,667 ****
  			     ;; Assume fixed-size chars
  			     (list 'space :align-to (1- pos))
! 			     header))))
      (with-current-buffer (get-buffer-create "*Buffer List*")
        (setq buffer-read-only nil)
--- 663,667 ----
  			     ;; Assume fixed-size chars
  			     (list 'space :align-to (1- pos))
! 			     header))) ;; )
      (with-current-buffer (get-buffer-create "*Buffer List*")
        (setq buffer-read-only nil)
***************
*** 672,676 ****
  	(insert (Buffer-menu-buffer+size "------" "----"))
  	(insert "  ----" mode-end "----\n")
! 	(put-text-property 1 (point) 'intangible t))
        (if buffer-list
  	  (setq list buffer-list)
--- 672,676 ----
  	(insert (Buffer-menu-buffer+size "------" "----"))
  	(insert "  ----" mode-end "----\n")
! 	(put-text-property 1 (point) 'fixed-pitch t))
        (if buffer-list
  	  (setq list buffer-list)

Diff finished.  Fri Nov 19 15:10:31 2004


Another bug:  when Buffer-menu-use-header-line is set to nil, even
though a keybinding appears as an echo area `tip' when you move the
mouse over a header line position, Buffer-menu-mouse-select fails.

Buffer-menu-mouse-select should succeed.  

Stephan Stahl suggested sort commands that could be attached to
keybindings.  This makes sense.  This could be done after the release.
For example:

    C-c C-s C-b for sort-buffername
    C-c C-s C-s for sort-size
    C-c C-s C-m for sort-mode
    C-c C-s C-f for sort-file
    C-c C-s C-u for sort-unsorted

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

Re: buff-menu.el header line

[Stefan Monnier]

> 	(put-text-property 1 (point) 'fixed-pitch t))

I don't think `fixed-pitch' is a property with any particular meaning, so
I suspect this doesn't do what you want it to.


        Stefan

Re: buff-menu.el header line

[Luc Teirlinck]

Stefan Monnier wrote:

   >  3. There may be more argument about deleting the line providing an
   >     intangible text property.  I always comment it out because its
   >     existence means I cannot use `C-n' (next-line) when point is in
   >     the header.  On the other hand, others may prefer only to use
   >     `C-f' (forward-char), which leaves the header line and its
   >     underlining.

   I don't particularly like `intangible', but the above suggests that a better
   solution is to fix C-n.

These are two different problems.  One is a (known but unfixed) bug
concerning line-move and the intangibility property.  The other is a
completely inappropriate use of the intangibility property, _regardless_
of that bug.

The use of the intangibility property in this instance is
inappropriate, because it has absolutely no benefit whatsoever to the
user and has several negative consequences.  One of the main reasons
to set `buffer-menu-use-header-line' to nil is to be able to move into
that text.  But this is exactly what the intangibility property wants
to prevent.  Why?  If the user does C-f at the beginning of a buffer,
it is with the purpose of moving to the right, not to move to the
third line.  The latter behavior is extremely surprising (and undesirable).

Sincerely,

Luc.

Re: buff-menu.el header line

[Andreas Schwab]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> The use of the intangibility property in this instance is
> inappropriate, because it has absolutely no benefit whatsoever to the
> user and has several negative consequences.  One of the main reasons
> to set `buffer-menu-use-header-line' to nil is to be able to move into
> that text.  But this is exactly what the intangibility property wants
> to prevent.  Why?  If the user does C-f at the beginning of a buffer,
> it is with the purpose of moving to the right, not to move to the
> third line.  The latter behavior is extremely surprising (and undesirable).

It would also be nice to be able to move into the header and invoke the
"sort by" function by typing RET on it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: buff-menu.el header line

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> It would also be nice to be able to move into the header and invoke the
> "sort by" function by typing RET on it.

No!!

The next "nice thing" would be to be able to move into the toolbar,
menu, or mode-line and select things there with RET.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: buff-menu.el header line

[Stephan Stahl]

Hi.

storm@cua.dk (Kim F. Storm) said:
> Andreas Schwab <schwab@suse.de> writes:
>
>> It would also be nice to be able to move into the header and invoke the
>> "sort by" function by typing RET on it.
>
> No!!
>
> The next "nice thing" would be to be able to move into the toolbar,
> menu, or mode-line and select things there with RET.

I agree with Kim.

However Andreas does have a point too. I see no reason not to add a few key
bindings to buff-menu.el to be able to sort the buffer.

Something like C-c C-s C-b for sort-buffername
               C-c C-s C-s for sort-size
               C-c C-s C-m for sort-mode
               C-c C-s C-f for sort-file
               C-c C-s C-u for sort-unsorted

Maybe this should be done after the release.

Stephan
-- 
Stephan Stahl

Re: buff-menu.el header line

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> It would also be nice to be able to move into the header and invoke the
>> "sort by" function by typing RET on it.
>
> No!!
>
> The next "nice thing" would be to be able to move into the toolbar,
> menu, or mode-line and select things there with RET.

Or into the minibuffer prompt and -- oops.  I don't think that
cut&paste really should be enough of a reason to move into minibuffer
prompts, header, toolbar, menus or modelines.

Same rules for everyone.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: buff-menu.el header line

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> It would also be nice to be able to move into the header and invoke the
>> "sort by" function by typing RET on it.
>
> No!!
>
> The next "nice thing" would be to be able to move into the toolbar,
> menu, or mode-line and select things there with RET.

The header is part of the buffer, the toolbar, menu and mode-line aren't.

I'm just looking for an alternative way to invoke the "sort by" function
with the keyboard.  Typing RET on an active button is consistent with
other uses.  But I agree that using new keybindings as Stephan suggested
is a good alternative.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: buff-menu.el header line

[Stephan Stahl]

Hi.

Andreas Schwab said:
> I'm just looking for an alternative way to invoke the "sort by" function
> with the keyboard.  Typing RET on an active button is consistent with
> other uses.  But I agree that using new keybindings as Stephan suggested
> is a good alternative.

This would be a first shot at it:
(based on buff-menu.el version 1.66, i think there was a thread to make
sorting more flexible, including sorting up/down but as far as i can see it
was not included in cvs so this should work with the current version 1.73)

(defun Buffer-menu-sort-visited ()
  "Sort by visited order."
  (interactive)
  (Buffer-menu-sort nil))

(defun Buffer-menu-sort-buffer ()
  "Sort by visited order."
  (interactive)
  (Buffer-menu-sort 2))

(defun Buffer-menu-sort-size ()
  "Sort by visited order."
  (interactive)
  (Buffer-menu-sort 3))

(defun Buffer-menu-sort-mode ()
  "Sort by visited order."
  (interactive)
  (Buffer-menu-sort 4))

(defun Buffer-menu-sort-file ()
  "Sort by visited order."
  (interactive)
  (Buffer-menu-sort 5))

(define-key Buffer-menu-mode-map "\C-c\C-s\C-v" 'Buffer-menu-sort-visited)
(define-key Buffer-menu-mode-map "\C-c\C-s\C-u" 'Buffer-menu-sort-visited)
(define-key Buffer-menu-mode-map "\C-c\C-s\C-b" 'Buffer-menu-sort-buffer)
(define-key Buffer-menu-mode-map "\C-c\C-s\C-s" 'Buffer-menu-sort-size)
(define-key Buffer-menu-mode-map "\C-c\C-s\C-m" 'Buffer-menu-sort-mode)
(define-key Buffer-menu-mode-map "\C-c\C-s\C-f" 'Buffer-menu-sort-file)

-- 
Stephan Stahl

RE: buff-menu.el header line

[Drew Adams]

    i think there was a thread to make sorting more flexible, including
    sorting up/down but as far as i can see it was not included in cvs

I wrote the patch to let you sort up or down by clicking on a header-line
column heading. The patch has not yet been added to Emacs, I believe,
because I am waiting for word from my employer on papers.

Re: buff-menu.el header line

[Robert J. Chassell]

    It would also be nice to be able to move into the header and
    invoke the "sort by" function by typing RET on it.

You can already invoke (Buffer-menu-sort 4) to sort the *Buffer List*
by Mode (the fourth column).  [ i.e., C-u 4 M-x Buffer-menu-sort RET  ]

So here is some sample code to enable you to type RET in the header
line of a *Buffer List* to sort by that column.

This works when Buffer-menu-use-header-line is set to nil and when
point is in the header line.  (Please note that this awkward
proof-of-concept code does not test for either condition.)

    (defun Buffer-menu-sort-on-column-position ()
      "Sort by column type in a *Buffer List*
    Point must be in the header line.
    Must set Buffer-menu-use-header-line to nil.

    Awkward proof-of-concept defun: 
    do not use except to show what can be done."
      (interactive)
      (let ((here (point))
            (column 0))
        (while (not (eq (point) (point-min)))
          (backward-word)
          (setq column (1+ column)))
        (Buffer-menu-sort column)))

Here is the keybinding.  This only works consistently if RET is
invoked from the header line.  (If evoked in the body of a *Buffer
List* with point at the end of the a line that says

  * *Shell Command Output*  68  Fundamental - Ex

i.e., point is in the Mode column, the function counts 6 columns from
the end ... so it sorts by File) 

Please remember, this is merely `proof of concept' code.

  (define-key 
    Buffer-menu-mode-map  "\C-m" 'Buffer-menu-sort-on-column-position))

I just tested this successfully (but very briefly) in an experimental
instance of Emacs with Buffer-menu-use-header-line set to nil.

I am not sure whether it is worth developing this.

Incidentally, even though the keybinding appears as an echo area `tip'
when you move the mouse over a header line column heading,
Buffer-menu-mouse-select fails when Buffer-menu-use-header-line is set
to nil.  It works fine when Buffer-menu-use-header-line is set to nil.


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

call-interactively: completion broken

[Robert J. Chassell]

Today's GNU Emacs CVS snapshot, Sun, 2004 Nov 21  13:00 UTC
GNU Emacs 21.3.50.14 (i686-pc-linux-gnu, GTK+ Version 2.4.13)
started with

    emacs -Q

Until recently, when I typed RET after typing enough of a command, the
command was executed, as described in the Emacs manual,  (emacs)Completion

Now, when I do this, I receive this error

    call-interactively: Symbol's function definition is void: forward-par

However, when I type TAB instead of RET, the completion occurs as it
should.

The only very recent revision to call-interactively, which is a C
`DEFUN', is this in emacs/src/callint.c

    revision 1.137
    date: 2004/11/21 00:59:35;  author: teirllm;  state: Exp;  lines: +1 -1
    (Fcall_interactively): Call Fread_from_minibuffer with extra argument.

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

Re: call-interactively: completion broken

[Luc Teirlinck]

Robert J. Chassell wrote:

   The only very recent revision to call-interactively, which is a C
   `DEFUN', is this in emacs/src/callint.c

       revision 1.137
       date: 2004/11/21 00:59:35;  author: teirllm;  state: Exp;  lines: +1 -1
       (Fcall_interactively): Call Fread_from_minibuffer with extra argument.

If you revert that change bootstrapping will fail.
Fread_from_minibuffer now _needs_ that extra argument.  This has to do
with minibuffer history and not completion.  The most recent change
affecting completion is Rev1.275 to minibuf.c.  I have seen other
people state that that change had bugs.  So this is the likely
culprit.  Of course, one could revert it to be sure.

Sincerely,

Luc.

Re: buff-menu.el header line

[Richard Stallman]

    > The use of the intangibility property in this instance is
    > inappropriate, because it has absolutely no benefit whatsoever to the
    > user and has several negative consequences.  One of the main reasons
    > to set `buffer-menu-use-header-line' to nil is to be able to move into
    > that text.  But this is exactly what the intangibility property wants
    > to prevent.  Why?  If the user does C-f at the beginning of a buffer,
    > it is with the purpose of moving to the right, not to move to the
    > third line.  The latter behavior is extremely surprising (and undesirable).

I agree, there is no reason for that text to be intangible.  I plan to
take that out, unless someone shows me a good reason to leave it in.

Re: buff-menu.el header line

[Richard Stallman]

    The misalignment can be fixed by deleting the space before the `CRM'
    in `list-buffers-noselect' on line 648 of emacs/lisp/buff-menu.el

    Change
	     (header (concat " " (propertize "CRM " 'face 'fixed-pitch)
    to
	     (header (concat (propertize "CRM " 'face 'fixed-pitch)

That space was obviously put there for a reason,
so this can't be a real fix.

What change was it that caused this bug to appear?

RE: buff-menu.el header line

[Drew Adams]

       The misalignment can be fixed by deleting the space before the `CRM'
        in `list-buffers-noselect' on line 648 of emacs/lisp/buff-menu.el

        Change
    	     (header (concat " " (propertize "CRM " 'face 'fixed-pitch)
        to
    	     (header (concat (propertize "CRM " 'face 'fixed-pitch)

    That space was obviously put there for a reason,
    so this can't be a real fix.

    What change was it that caused this bug to appear?

Just a guess, but in Emacs 20 the header has " MR Buffer " instead of "CRM
Buffer ". Perhaps, instead of the C replacing the initial space, it was
added after it.

BTW, there is nothing particularly mnemonic about "CRM". I suspect that most
users will never guess what the letters stand for...and they don't need to.
I suggest we remove "CRM" altogether: it hurts more than helps
understanding.