bug#1779: 23.0.60; proced with variable-pitch header line

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

Proced does not align the attribute names in the header line with the
corresponding columns when header-line face has variable pitch.  To
reproduce:

1. emacs -Q
2. customize-face RET header-line RET, change the value of the inherit
   attribute to variable-pitch and the value of the height attribute to
   0.85, and set for the current session.
3. M-x proced

I know of two approaches to dealing with this situation in Emacs, namely
that of buff-menu.el and that of ibuffer.el.  The latter imposes a
fixed-pitch face in the header line, overriding the
user customization.  The former uses the display property with an
:align-to specification to get proper alignment.  Maybe one of these
will work with proced.el too.

In GNU Emacs 23.0.60.27 (i686-pc-linux-gnu, GTK+ Version 2.12.9)
 of 2009-01-03 on escher

bug#1779: 23.0.60; proced with variable-pitch header line

[Chong Yidong]

> Proced does not align the attribute names in the header line with the
> corresponding columns when header-line face has variable pitch.
>
> I know of two approaches to dealing with this situation in Emacs, namely
> that of buff-menu.el and that of ibuffer.el.  The latter imposes a
> fixed-pitch face in the header line, overriding the
> user customization.  The former uses the display property with an
> :align-to specification to get proper alignment.  Maybe one of these
> will work with proced.el too.

We can't use :align-to because proced justifies some headers to the
right hand side of the column.

I don't see where ibuffer.el imposes a fixed-pitch face on the header
line, though.  Can you point out where it does this?

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

On Sun, 04 Jan 2009 03:23:53 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:

>> Proced does not align the attribute names in the header line with the
>> corresponding columns when header-line face has variable pitch.
>>
>> I know of two approaches to dealing with this situation in Emacs, namely
>> that of buff-menu.el and that of ibuffer.el.  The latter imposes a
>> fixed-pitch face in the header line, overriding the
>> user customization.  The former uses the display property with an
>> :align-to specification to get proper alignment.  Maybe one of these
>> will work with proced.el too.
>
> We can't use :align-to because proced justifies some headers to the
> right hand side of the column.

The justification is customizable in proced-grammar-alist.  I set it to
`left' for all headers and modified proced-format by adapting the
:align-to code from buff-menu.el, but the headers still failed to align
with the columns with a variable-pitch header-line face.  But shouldn't
it be possible in principle?  Maybe someone who knows the code better
can make it work.

> I don't see where ibuffer.el imposes a fixed-pitch face on the header
> line, though.  Can you point out where it does this?

I made two mistakes here, sorry.  First, I shouldn't have said
fixed-pitch but the same face as is used in the buffer (which has to be
fixed-pitch in order for the columns to be aligned).  But in addition,
what I assumed to be the header line in the ibuffer window is in fact
just the first line of the buffer (although I looked at the ibuffer code
and saw ibuffer-header-line-format, I overlooked that this was only for
filters, and unthinkingly took the first line to be a header line, as
with buff-menu).  It's too bad the ibuffer "header" line isn't fixed
with respect to the rest of the buffer when scrolling, like a real
header line.  Could this effect be achieved with an overlay?

Steve Berman

bug#1779: 23.0.60; proced with variable-pitch header line

[Stefan Monnier]

> The justification is customizable in proced-grammar-alist.  I set it to
> `left' for all headers and modified proced-format by adapting the
> :align-to code from buff-menu.el, but the headers still failed to align
> with the columns with a variable-pitch header-line face.  But shouldn't
> it be possible in principle?  Maybe someone who knows the code better
> can make it work.

You can also take a look at mpc.el
(bzr co http://www.iro.umontreal.ca/~monnier/bzr/mpc) where I do it with
align-to as well.  I "try" to handle right alignment, but in a very
naive way.  I don't think we can currently do it right in Elisp, because
there is a lot of missing information.  I could imagine getting it to
work, with a lot of effort based on forcing redisplay and using
posn-at-point to measure the display size of particular pieces of text.
But it's likely to be too slow to be practical.


        Stefan

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

On Sun, 04 Jan 2009 03:23:53 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:

>> Proced does not align the attribute names in the header line with the
>> corresponding columns when header-line face has variable pitch.
>>
>> I know of two approaches to dealing with this situation in Emacs, namely
>> that of buff-menu.el and that of ibuffer.el.  The latter imposes a
>> fixed-pitch face in the header line, overriding the
>> user customization.  The former uses the display property with an
>> :align-to specification to get proper alignment.  Maybe one of these
>> will work with proced.el too.
>
> We can't use :align-to because proced justifies some headers to the
> right hand side of the column.

I (finally) took a look at this again and it appears that :align-to as
used in buff-menu.el with some additional tweaking pretty much DTRT
after all.  With my variable-pitch font (Dejavu Sans) I find the spacing
between "%CPU" and "%Mem" too crowded; using fixed-pitch looks better,
and that's what the attached patch does.  Alternatively, I think it
looks fine to let the header line font be variable-pitch as long as the
let-bound variable whitespace is set to two spaces.  I actually think
this makes the proced listings also more legible, though it does leave
less space for the process invocation listing and is also a departure
from the Dired display that Proced is modelled on.  Anyway, I'd be happy
with either approach; both are better than the current display when the
header-line face is variable-pitch.

Steve Berman


*** /data/steve/bzr/emacs/trunk/lisp/proced.el	2010-09-08 10:12:09.000000000 +0200
--- /data/steve/bzr/emacs/quickfixes/lisp/proced.el	2010-12-06 00:02:20.000000000 +0100
***************
*** 400,406 ****
    :group 'proced-faces)
  
  (defface proced-sort-header
!   '((t (:inherit font-lock-keyword-face)))
    "Face used for header of attribute used for sorting."
    :group 'proced-faces)
  
--- 400,406 ----
    :group 'proced-faces)
  
  (defface proced-sort-header
!   '((t (:family "Monospace" :inherit font-lock-keyword-face)))
    "Face used for header of attribute used for sorting."
    :group 'proced-faces)
  
***************
*** 1427,1433 ****
               (hprops
                (if (nth 4 grammar)
                    (let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
!                     `(proced-key ,key mouse-face highlight
                                   help-echo ,(format proced-header-help-echo
                                                      (if descend "-" "+")
                                                      (nth 1 grammar)
--- 1427,1433 ----
               (hprops
                (if (nth 4 grammar)
                    (let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
!                     `(proced-key ,key face fixed-pitch mouse-face highlight
                                   help-echo ,(format proced-header-help-echo
                                                      (if descend "-" "+")
                                                      (nth 1 grammar)
***************
*** 1509,1514 ****
--- 1509,1525 ----
      (if (string-match "[ \t]+$" proced-header-line)
          (setq proced-header-line (substring proced-header-line 0
                                              (match-beginning 0))))
+     (setq proced-header-line (concat "  " proced-header-line))
+     ;; From buff-menu.el: Turn whitespace chars in the header into stretch
+     ;; specs so they work regardless of the header-line face.
+     (let ((pos 0)
+     	  (header proced-header-line))
+     	(while (string-match "[ \t\n]+" header pos)
+     	  (setq pos (match-end 0))
+     	  (put-text-property (match-beginning 0) pos 'display
+     			     ;; Assume fixed-size chars in the buffer.
+     			     (list 'space :align-to pos)
+     			     header)))
      ;; (delete-trailing-whitespace)
      (goto-char (point-min))
      (while (re-search-forward "[ \t\r]+$" nil t)

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 2102 bytes --]

On Mon, 06 Dec 2010 00:30:17 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Sun, 04 Jan 2009 03:23:53 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:
>
>>> Proced does not align the attribute names in the header line with the
>>> corresponding columns when header-line face has variable pitch.
>>>
>>> I know of two approaches to dealing with this situation in Emacs, namely
>>> that of buff-menu.el and that of ibuffer.el.  The latter imposes a
>>> fixed-pitch face in the header line, overriding the
>>> user customization.  The former uses the display property with an
>>> :align-to specification to get proper alignment.  Maybe one of these
>>> will work with proced.el too.
>>
>> We can't use :align-to because proced justifies some headers to the
>> right hand side of the column.
>
> I (finally) took a look at this again and it appears that :align-to as
> used in buff-menu.el with some additional tweaking pretty much DTRT
> after all.  With my variable-pitch font (Dejavu Sans) I find the spacing
> between "%CPU" and "%Mem" too crowded; using fixed-pitch looks better,
> and that's what the attached patch does.  Alternatively, I think it
> looks fine to let the header line font be variable-pitch as long as the
> let-bound variable whitespace is set to two spaces.  I actually think
> this makes the proced listings also more legible, though it does leave
> less space for the process invocation listing and is also a departure
> from the Dired display that Proced is modelled on.  Anyway, I'd be happy
> with either approach; both are better than the current display when the
> header-line face is variable-pitch.

There was an oversight in my patch; the corrected version is below.
Also, I attach three screenshots: the first shows what the Proced
display generated by the current code looks like when the header line
face is variable-pitch, the second show the display using the below
patch (with the header line stretched and set to fixed-pitch), the third
shows the alternative mentioned above (with stretched variable-pitch
header line and added space).

Steve Berman


[-- Attachment #2: Proced with unstretched variable-pitch header line --]
[-- Type: image/png, Size: 17034 bytes --]

[-- Attachment #3: Proced with stretched fixed-pitch header line --]
[-- Type: image/png, Size: 14575 bytes --]

[-- Attachment #4: Proced with stretched variable-pitch header line --]
[-- Type: image/png, Size: 14965 bytes --]

[-- Attachment #5: Type: text/plain, Size: 2725 bytes --]


*** /data/steve/bzr/emacs/trunk/lisp/proced.el	2010-09-08 10:12:09.000000000 +0200
--- /data/steve/bzr/emacs/quickfixes/lisp/proced.el	2010-12-07 11:15:38.000000000 +0100
***************
*** 400,406 ****
    :group 'proced-faces)
  
  (defface proced-sort-header
!   '((t (:inherit font-lock-keyword-face)))
    "Face used for header of attribute used for sorting."
    :group 'proced-faces)
  
--- 400,406 ----
    :group 'proced-faces)
  
  (defface proced-sort-header
!   '((t (:family "Monospace" :inherit font-lock-keyword-face)))
    "Face used for header of attribute used for sorting."
    :group 'proced-faces)
  
***************
*** 1427,1433 ****
               (hprops
                (if (nth 4 grammar)
                    (let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
!                     `(proced-key ,key mouse-face highlight
                                   help-echo ,(format proced-header-help-echo
                                                      (if descend "-" "+")
                                                      (nth 1 grammar)
--- 1427,1433 ----
               (hprops
                (if (nth 4 grammar)
                    (let ((descend (if (eq key sort-key) proced-descend (nth 5 grammar))))
!                     `(proced-key ,key face fixed-pitch mouse-face highlight
                                   help-echo ,(format proced-header-help-echo
                                                      (if descend "-" "+")
                                                      (nth 1 grammar)
***************
*** 1509,1514 ****
--- 1509,1525 ----
      (if (string-match "[ \t]+$" proced-header-line)
          (setq proced-header-line (substring proced-header-line 0
                                              (match-beginning 0))))
+     (setq proced-header-line (concat "  " proced-header-line))
+     ;; From buff-menu.el: Turn whitespace chars in the header into stretch
+     ;; specs so they work regardless of the header-line face.
+     (let ((pos 0)
+     	  (header proced-header-line))
+     	(while (string-match "[ \t\n]+" header pos)
+     	  (setq pos (match-end 0))
+     	  (put-text-property (match-beginning 0) pos 'display
+     			     ;; Assume fixed-size chars in the buffer.
+     			     (list 'space :align-to pos)
+     			     header)))
      ;; (delete-trailing-whitespace)
      (goto-char (point-min))
      (while (re-search-forward "[ \t\r]+$" nil t)
***************
*** 1602,1608 ****
      (while (not (eobp))
        (insert "  ")
        (forward-line))
-     (setq proced-header-line (concat "  " proced-header-line))
      (if revert (set-buffer-modified-p nil))
  
      ;; set `goal-column'
--- 1613,1618 ----

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> There was an oversight in my patch; the corrected version is below.
> Also, I attach three screenshots: the first shows what the Proced
> display generated by the current code looks like when the header line
> face is variable-pitch, the second show the display using the below
> patch (with the header line stretched and set to fixed-pitch), the third
> shows the alternative mentioned above (with stretched variable-pitch
> header line and added space).

The images included shows that the patch made an improvement.  Was there
any reason it wasn't applied at the time?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1779: 23.0.60; proced with variable-pitch header line

[Stefan Monnier]

>> There was an oversight in my patch; the corrected version is below.
>> Also, I attach three screenshots: the first shows what the Proced
>> display generated by the current code looks like when the header line
>> face is variable-pitch, the second show the display using the below
>> patch (with the header line stretched and set to fixed-pitch), the third
>> shows the alternative mentioned above (with stretched variable-pitch
>> header line and added space).

> The images included shows that the patch made an improvement.  Was there
> any reason it wasn't applied at the time?

I guess lack of time.  I don't think I agree with the change to the face
definition, but the part of the code that adds :align-to properties to
the spaces looks fine.


        Stefan

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I guess lack of time.  I don't think I agree with the change to the face
> definition, but the part of the code that adds :align-to properties to
> the spaces looks fine.

Stephen, could you send an updated patch with just the :align-to
properties?  (If that makes any sense.  :-)  I'm not familiar enough
with the code to know whether that would be an improvement or not
without the other bits in the patch.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

On Fri, 15 Jul 2011 19:54:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> I guess lack of time.  I don't think I agree with the change to the face
>> definition, but the part of the code that adds :align-to properties to
>> the spaces looks fine.
>
> Stephen, could you send an updated patch with just the :align-to
> properties?  (If that makes any sense.  :-)  I'm not familiar enough
> with the code to know whether that would be an improvement or not
> without the other bits in the patch.)

Sure.  I'll do it as soon as I can, but I probably won't have time until
Monday or Tuesday.

Steve Berman

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

On Fri, 15 Jul 2011 23:05:59 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Fri, 15 Jul 2011 19:54:11 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>> I guess lack of time.  I don't think I agree with the change to the face
>>> definition, but the part of the code that adds :align-to properties to
>>> the spaces looks fine.
>>
>> Stephen, could you send an updated patch with just the :align-to
>> properties?  (If that makes any sense.  :-)  I'm not familiar enough
>> with the code to know whether that would be an improvement or not
>> without the other bits in the patch.)
>
> Sure.  I'll do it as soon as I can, but I probably won't have time until
> Monday or Tuesday.

The patch is below.  The only change I made from the previous patch
(aside from leaving out the face change) is to omit the comment from
buff-menu.el about assuming fixed-pitch, since obviously we aren't
making that assumption (though it's true that :align-to works best with
fixed-pitch, but still I definitely think it's an improvement).

Steve Berman


*** /home/steve/bzr/emacs/trunk/lisp/proced.el	2011-07-08 15:13:26.000000000 +0200
--- /home/steve/bzr/emacs/quickfixes/lisp/proced.el	2011-07-19 23:06:48.000000000 +0200
***************
*** 1509,1514 ****
--- 1509,1524 ----
      (if (string-match "[ \t]+$" proced-header-line)
          (setq proced-header-line (substring proced-header-line 0
                                              (match-beginning 0))))
+      (setq proced-header-line (concat "  " proced-header-line))
+      ;; From buff-menu.el: Turn whitespace chars in the header into
+      ;; stretch specs so they work regardless of the header-line face.
+      (let ((pos 0)
+      	  (header proced-header-line))
+      	(while (string-match "[ \t\n]+" header pos)
+      	  (setq pos (match-end 0))
+      	  (put-text-property (match-beginning 0) pos 'display
+      			     (list 'space :align-to pos)
+      			     header)))
      ;; (delete-trailing-whitespace)
      (goto-char (point-min))
      (while (re-search-forward "[ \t\r]+$" nil t)
***************
*** 1602,1608 ****
      (while (not (eobp))
        (insert "  ")
        (forward-line))
-     (setq proced-header-line (concat "  " proced-header-line))
      (if revert (set-buffer-modified-p nil))
  
      ;; set `goal-column'
--- 1612,1617 ----

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> The patch is below.  The only change I made from the previous patch
> (aside from leaving out the face change) is to omit the comment from
> buff-menu.el about assuming fixed-pitch, since obviously we aren't
> making that assumption (though it's true that :align-to works best with
> fixed-pitch, but still I definitely think it's an improvement).

Thanks; I've now applied the patch.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1779: 23.0.60; proced with variable-pitch header line

[Roland Winkler]

On Tue, Jul 19 2011, Stephen Berman wrote:
> The patch is below.  The only change I made from the previous patch
> (aside from leaving out the face change) is to omit the comment from
> buff-menu.el about assuming fixed-pitch, since obviously we aren't
> making that assumption (though it's true that :align-to works best with
> fixed-pitch, but still I definitely think it's an improvement).

I am sorry, this patch does not work for me!

I do not use variable-pitch fonts. But I use the longer proced formats.
With the new code the header line does not scroll horizontally anymore
as required for the longer proced formats.
Yet stranger, when scrolling the proced buffer to the right, some
headers on the left simply disappear, whereas headers on the right part
of the window stay where they are. So for the long proced formats, the
header line has become rather useless. -- What is more annoying: the old
wrong behavior for variable-pitch fonts or the new behavior?

Roland

PS: I just installed a patch for proced that should be completely unrelated.

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

On Tue, 19 Jul 2011 20:18:04 -0500 Roland Winkler <winkler@gnu.org> wrote:

> On Tue, Jul 19 2011, Stephen Berman wrote:
>> The patch is below.  The only change I made from the previous patch
>> (aside from leaving out the face change) is to omit the comment from
>> buff-menu.el about assuming fixed-pitch, since obviously we aren't
>> making that assumption (though it's true that :align-to works best with
>> fixed-pitch, but still I definitely think it's an improvement).
>
> I am sorry, this patch does not work for me!

> I do not use variable-pitch fonts. But I use the longer proced formats.
> With the new code the header line does not scroll horizontally anymore
> as required for the longer proced formats.
> Yet stranger, when scrolling the proced buffer to the right, some
> headers on the left simply disappear, whereas headers on the right part
> of the window stay where they are. So for the long proced formats, the
> header line has become rather useless. -- What is more annoying: the old
> wrong behavior for variable-pitch fonts or the new behavior?

Certainly the new behavior is untenable; please revert my patch.  I
didn't know about the long format and didn't test it.  I took a quick
look but couldn't come up with a quick fix.  I'll try some more when I
have time, but it won't be soon; if you or somebody else can find a fix,
that would be great.  Or maybe this problem is a good argument for
hardcoding fixed-pitch for the proced header line.

Sorry for the poorly tested patch.

Steve Berman

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Magne Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> Certainly the new behavior is untenable; please revert my patch.

I've now reverted the patch and reopened this report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#1779: 23.0.60; proced with variable-pitch header line

[Roland Winkler]

On Wed Jul 20 2011 Stephen Berman wrote:
> Certainly the new behavior is untenable; please revert my patch.  I
> didn't know about the long format and didn't test it.  I took a quick
> look but couldn't come up with a quick fix.  I'll try some more when I
> have time, but it won't be soon; if you or somebody else can find a fix,
> that would be great.  Or maybe this problem is a good argument for
> hardcoding fixed-pitch for the proced header line.

Right now it's not clear to me where things went wrong with your
patch. The behavior I got did not make sense to me under any
circumstances. So possibly this really indicated that things are
going wrong elsewhere. I want to take a closer look at this, too.

I am sorry I missed your original bug report.

Roland

bug#1779: 23.0.60; proced with variable-pitch header line

[Chong Yidong]

"Roland Winkler" <winkler@gnu.org> writes:

> On Wed Jul 20 2011 Stephen Berman wrote:
>> Certainly the new behavior is untenable; please revert my patch.  I
>> didn't know about the long format and didn't test it.  I took a quick
>> look but couldn't come up with a quick fix.  I'll try some more when I
>> have time, but it won't be soon; if you or somebody else can find a fix,
>> that would be great.  Or maybe this problem is a good argument for
>> hardcoding fixed-pitch for the proced header line.
>
> Right now it's not clear to me where things went wrong with your
> patch. The behavior I got did not make sense to me under any
> circumstances. So possibly this really indicated that things are
> going wrong elsewhere. I want to take a closer look at this, too.
>
> I am sorry I missed your original bug report.

AFAICT, the alignment issue does not occur in Tabulated List mode, which
uses :align-to.  In the short run, you might be able to get a clue about
the correct fix from there.  In the long run, I think proced.el should
be reworked to use Tabulated List mode.

bug#1779: 23.0.60; proced with variable-pitch header line

[Roland Winkler]

On Thu Jul 21 2011 Chong Yidong wrote:
> AFAICT, the alignment issue does not occur in Tabulated List mode, which
> uses :align-to.  In the short run, you might be able to get a clue about
> the correct fix from there.  In the long run, I think proced.el should
> be reworked to use Tabulated List mode.

Thanks, I'll have to find out what Tabulated List mode is doing.
I am just wondering: In general, proced was much inspired by dired.
Would you suggest that dired should likewise use Tabulated List mode?

Roland

bug#1779: 23.0.60; proced with variable-pitch header line

[Chong Yidong]

"Roland Winkler" <winkler@gnu.org> writes:

> Thanks, I'll have to find out what Tabulated List mode is doing.
> I am just wondering: In general, proced was much inspired by dired.
> Would you suggest that dired should likewise use Tabulated List mode?

T-L mode is not suitable for Dired, because not every line is an
"entry", i.e. the first two summary lines---which are also the reason
why Dired does not use the header line.  Other Dired features, like
showing multiple directories, also break T-L mode assumptions.

One mode that could be usefully converted to use T-L mode is Buffer Menu
mode.  Maybe we'll get round to that in a future major Emacs version.

bug#1779: 23.0.60; proced with variable-pitch header line

[Stefan Monnier]

>> Certainly the new behavior is untenable; please revert my patch.
> I've now reverted the patch and reopened this report.

I fixed the patch so it also works correctly when
scrolling horizontally.


        Stefan

bug#1779: 23.0.60; proced with variable-pitch header line

[Stephen Berman]

On Sun, 11 Oct 2020 18:22:47 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>>> Certainly the new behavior is untenable; please revert my patch.
>> I've now reverted the patch and reopened this report.
>
> I fixed the patch so it also works correctly when
> scrolling horizontally.

Thanks!

Steve Berman

bug#1779: 23.0.60; proced with variable-pitch header line

[Juri Linkov]

>>> Certainly the new behavior is untenable; please revert my patch.
>> I've now reverted the patch and reopened this report.
>
> I fixed the patch so it also works correctly when
> scrolling horizontally.

As discussed in
https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00084.html
I tried to fix this bug in the emacs-28 branch by copying code
from ‘tabulated-list-col-sort’ to ‘proced-sort-header’.

Maybe now variable-pitch could be enabled on proced-head-line.

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> As discussed in
> https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00084.html
> I tried to fix this bug in the emacs-28 branch by copying code
> from ‘tabulated-list-col-sort’ to ‘proced-sort-header’.
>
> Maybe now variable-pitch could be enabled on proced-head-line.

I'm not quite sure whether having the header line in a proportional font
when the rest of the text is monospaced is ideal -- it can sometimes
look pretty odd.

We should have a package for doing variable-pitch tables, and I've been
working on one, but I want to reimplement it before including in Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#1779: 23.0.60; proced with variable-pitch header line

[Juri Linkov]

>> Maybe now variable-pitch could be enabled on proced-head-line.
>
> I'm not quite sure whether having the header line in a proportional font
> when the rest of the text is monospaced is ideal -- it can sometimes
> look pretty odd.
>
> We should have a package for doing variable-pitch tables, and I've been
> working on one, but I want to reimplement it before including in Emacs.

Agreed, when tabulated-list-mode will support variable-pitch tables,
and proced will use tabulated-list-mode, only then its header line
could be in variable-pitch.

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Agreed, when tabulated-list-mode will support variable-pitch tables,
> and proced will use tabulated-list-mode, only then its header line
> could be in variable-pitch.

I had in mind a bigger change than that.  😀  tabulated-list-mode is
nice, but there's things about it that makes it less suited to some work
flows, so I'd like to make a new package for this.

The main problem is that it wants to own the buffer, and you can only
have the table in it, and nothing else.  The other issue is that the
interface functions are a bit obscure -- you set/manipulate a bunch of
buffer-local variables, and then call some functions.

I'd like to have a table that's an "object", with well-defined interface
functions, and which allows you to have many tables in the same buffer,
and mix with other text, too.

And with proportional fonts.  😀

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#1779: [External] : bug#1779: 23.0.60; proced with variable-pitch header line

[Drew Adams]

> I had in mind a bigger change than that.  😀  tabulated-list-mode is
> nice, but there's things about it that makes it less suited to some work
> flows, so I'd like to make a new package for this.
> 
> The main problem is that it wants to own the buffer, and you can only
> have the table in it, and nothing else.

Yes, I've said that many times.  Glad it's finally
sunk in.  That's a sufficient reason that it should
not have been used in things like the bookmark list.
(Even adding it to buffer-menu was a mistake.)

> The other issue is that the
> interface functions are a bit obscure -- you set/manipulate a bunch of
> buffer-local variables, and then call some functions.

A more important weakness of t-l-mode is that it
doesn't support arbitrary sort functions - it
doesn't make it easy to sort other than by an
individual column.  

> I'd like to have a table that's an "object", with well-defined interface
> functions, and which allows you to have many tables in the same buffer,
> and mix with other text, too.
> 
> And with proportional fonts.  😀

To me, t-l-mode is too limited for most real,
useful uses of "tabular" data.  It should never
have been imposed on the bookmark list (I don't
use it in Bookmark+).  And it's useless for
things like Dired (thank goodness).  Maybe the
same for Ibuffer; dunno.

bug#1779: 23.0.60; proced with variable-pitch header line

[Juri Linkov]

> I'd like to have a table that's an "object", with well-defined interface
> functions, and which allows you to have many tables in the same buffer,
> and mix with other text, too.

I wonder how several tables could share the same header-line?
Or it would be possible to implement own header for each table
(not using the window header-line)?
Then each table could be scrolled separately.

bug#1779: 23.0.60; proced with variable-pitch header line

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov [2021-11-29 19:16:04] wrote:
>> I'd like to have a table that's an "object", with well-defined interface
>> functions, and which allows you to have many tables in the same buffer,
>> and mix with other text, too.
> I wonder how several tables could share the same header-line?
> Or it would be possible to implement own header for each table
> (not using the window header-line)?
> Then each table could be scrolled separately.

A `pre-redisplay-function` that looks at `window-start` and sets
the `header-line` accordingly might work.


        Stefan

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> A `pre-redisplay-function` that looks at `window-start` and sets
> the `header-line` accordingly might work.

Hm...  interesting.  Do we do something similar to this elsewhere in Emacs?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#1779: 23.0.60; proced with variable-pitch header line

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-11-29 19:47:11] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> A `pre-redisplay-function` that looks at `window-start` and sets
>> the `header-line` accordingly might work.
> Hm...  interesting.  Do we do something similar to this elsewhere in Emacs?

tabulated-list.el uses `pre-redisplay-function` to (re)set the
header-line in accordance to the line-number width.  That's not quite
the same but the key words do match ;-)


        Stefan

bug#1779: 23.0.60; proced with variable-pitch header line

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> Proced does not align the attribute names in the header line with the
> corresponding columns when header-line face has variable pitch.  To
> reproduce:
>
> 1. emacs -Q
> 2. customize-face RET header-line RET, change the value of the inherit
>    attribute to variable-pitch and the value of the height attribute to
>    0.85, and set for the current session.
> 3. M-x proced

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This has apparently been fixed in the years since it was reported -- I
can reproduce it in Emacs 25.3, for instance, but it Emacs 29, the
headings line up pretty well when using variable pitch in the headers in
proced.

So I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no