GNU bug report logs - #44068
28.0.50; Faulty uses of tabulated-list-format

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44068 in the body.
You can then email your comments to 44068 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Faulty uses of tabulated-list-format
Date: Sun, 18 Oct 2020 22:00:13 +0200

[Message part 1 (text/plain, inline)]

On trying out the new tabulated-list implementation of the bookmarks
list I noticed that, when clicking on the File header, the sort
indicator is not displayed, unlike with the Bookmark header.  Then I
noticed that the same thing happens in the tabulated buffer list (C-x
C-b).  Then I grepped for all uses of tabulated-list-format in the Emacs
sources and found the same problem in most of them.  The reason is that
in these modes the width of at least one of the columns is too narrow,
so that tabulated-list-init-header omits the indicator.  In most cases
the problematic column is the final one, but in a couple of cases there
are also non-final too narrow columns.  And I think these bugs are due
to a misleading description in tabulated-list-format's doc string.  The
attached patch corrects the doc string and the problematic uses of
tabulated-list-format.  The patch also fixes a typo and tries to improve
column alignment in timer-list-mode: this is one of the few modes
derived from tabulated-list-mode whose column widths didn't need to be
corrected, but the alignment seemed suboptimal; however, when the header
line uses a variable-pitch face, the alignment is still suboptimal even
with the patch, and I don't know how to fix that.

In GNU Emacs 28.0.50 (build 34, x86_64-pc-linux-gnu, GTK+ Version 3.24.17, cairo version 1.17.3)
 of 2020-10-18 built on strobe-jhalfs
Repository revision: b7dfae3a8168977013e8de1df0916c51e76e7326
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Linux From Scratch SVN-20200401


2020-10-18  Stephen Berman  <stephen.berman <at> gmx.net>

	Fix uses of tabulated-list-format

	* lisp/emacs-lisp/tabulated-list.el (tabulated-list-format):
	Correct the documentation of the WIDTH element.

	* lisp/bookmark.el (bookmark-bmenu-mode):
	* lisp/buff-menu.el (list-buffers--refresh):
	* lisp/emacs-lisp/package.el (package-menu-mode)
	(package-archive-column-width):
	* lisp/misc.el (list-dynamic-libraries--refresh):
	* lisp/org/org-lint.el (org-lint--report-mode):
	* lisp/progmodes/flymake.el (flymake-diagnostics-buffer-mode):
	* lisp/simple.el (process-menu-mode): Increase column width in
	order to display sort indicator.

	* lisp/emacs-lisp/timer-list.el (timer-list-mode): Improve column
	alignment.
	(timer-list--function-predicate): Correct typo in doc string.

[Message part 2 (text/x-patch, attachment)]

Message #8 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stephen Berman <stephen.berman <at> gmx.net>, 44068 <at> debbugs.gnu.org
Subject: RE: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Sun, 18 Oct 2020 14:33:18 -0700 (PDT)

> On trying out the new tabulated-list implementation of the bookmarks
> list I noticed that, when clicking on the File header, the sort
> indicator is not displayed, unlike with the Bookmark header.  Then I
> noticed that the same thing happens in the tabulated buffer list (C-x
> C-b).  Then I grepped for all uses of tabulated-list-format in the Emacs
> sources and found the same problem in most of them.  The reason is that
> in these modes the width of at least one of the columns is too narrow,
> so that tabulated-list-init-header omits the indicator.  In most cases
> the problematic column is the final one, but in a couple of cases there
> are also non-final too narrow columns.  And I think these bugs are due
> to a misleading description in tabulated-list-format's doc string.  The
> attached patch corrects the doc string and the problematic uses of
> tabulated-list-format.  The patch also fixes a typo and tries to improve
> column alignment in timer-list-mode: this is one of the few modes
> derived from tabulated-list-mode whose column widths didn't need to be
> corrected, but the alignment seemed suboptimal; however, when the header
> line uses a variable-pitch face, the alignment is still suboptimal even
> with the patch, and I don't know how to fix that.

This rings a bell (maybe).  I think the sort-indicator
problem might be a duplicate bug report, but I can't
find the dup now.  There are some inherent problems
with the rightmost column, IIRC, that being one of them.

(Dunno whether this helps at all.  Probably not.)

Message #11 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Sun, 18 Oct 2020 15:01:31 -0700

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

> On trying out the new tabulated-list implementation of the bookmarks
> list I noticed that, when clicking on the File header, the sort
> indicator is not displayed, unlike with the Bookmark header.  Then I
> noticed that the same thing happens in the tabulated buffer list (C-x
> C-b).  Then I grepped for all uses of tabulated-list-format in the Emacs
> sources and found the same problem in most of them.  The reason is that
> in these modes the width of at least one of the columns is too narrow,
> so that tabulated-list-init-header omits the indicator.  In most cases
> the problematic column is the final one, but in a couple of cases there
> are also non-final too narrow columns.  And I think these bugs are due
> to a misleading description in tabulated-list-format's doc string.

Your analysis sounds correct to me.

> The attached patch corrects the doc string and the problematic uses of
> tabulated-list-format.  The patch also fixes a typo and tries to
> improve column alignment in timer-list-mode: this is one of the few
> modes derived from tabulated-list-mode whose column widths didn't need
> to be corrected, but the alignment seemed suboptimal; however, when
> the header line uses a variable-pitch face, the alignment is still
> suboptimal even with the patch, and I don't know how to fix that.

Thanks for the patch.  I've tested it and it indeed fixes several bugs
in this area.

But it got me thinking: for the final column at least, maybe we should
just make tabulated-list-mode work as advertised, and itself figure out
that it should use this length?  That way, we would solve any bugs also
for external packages that have been misled by the doc string.  Or would
that have any downsides?

Message #14 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>, Stephen Berman <stephen.berman <at> gmx.net>,
 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Sun, 18 Oct 2020 15:01:47 -0700

Drew Adams <drew.adams <at> oracle.com> writes:

> This rings a bell (maybe).  I think the sort-indicator
> problem might be a duplicate bug report, but I can't
> find the dup now.  There are some inherent problems
> with the rightmost column, IIRC, that being one of them.

Maybe Bug#41861?

Message #17 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, Stephen Berman
 <stephen.berman <at> gmx.net>, 44068 <at> debbugs.gnu.org
Subject: RE: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Sun, 18 Oct 2020 15:15:28 -0700 (PDT)

> > This rings a bell (maybe).  I think the sort-indicator
> > problem might be a duplicate bug report, but I can't
> > find the dup now.  There are some inherent problems
> > with the rightmost column, IIRC, that being one of them.
> 
> Maybe Bug#41861?

Yeah, probably.  Thx.

Message #20 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 00:17:12 +0200

On Sun, 18 Oct 2020 15:01:31 -0700 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On trying out the new tabulated-list implementation of the bookmarks
>> list I noticed that, when clicking on the File header, the sort
>> indicator is not displayed, unlike with the Bookmark header.  Then I
>> noticed that the same thing happens in the tabulated buffer list (C-x
>> C-b).  Then I grepped for all uses of tabulated-list-format in the Emacs
>> sources and found the same problem in most of them.  The reason is that
>> in these modes the width of at least one of the columns is too narrow,
>> so that tabulated-list-init-header omits the indicator.  In most cases
>> the problematic column is the final one, but in a couple of cases there
>> are also non-final too narrow columns.  And I think these bugs are due
>> to a misleading description in tabulated-list-format's doc string.
>
> Your analysis sounds correct to me.
>
>> The attached patch corrects the doc string and the problematic uses of
>> tabulated-list-format.  The patch also fixes a typo and tries to
>> improve column alignment in timer-list-mode: this is one of the few
>> modes derived from tabulated-list-mode whose column widths didn't need
>> to be corrected, but the alignment seemed suboptimal; however, when
>> the header line uses a variable-pitch face, the alignment is still
>> suboptimal even with the patch, and I don't know how to fix that.
>
> Thanks for the patch.  I've tested it and it indeed fixes several bugs
> in this area.
>
> But it got me thinking: for the final column at least, maybe we should
> just make tabulated-list-mode work as advertised, and itself figure out
> that it should use this length?  That way, we would solve any bugs also
> for external packages that have been misled by the doc string.  Or would
> that have any downsides?

That was my first thought when I noticed the problem, and came up with
this patch to fix it:

diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
index b13f609f88..d6bec72ade 100644
--- a/lisp/emacs-lisp/tabulated-list.el
+++ b/lisp/emacs-lisp/tabulated-list.el
@@ -271,11 +271,12 @@ tabulated-list-init-header
 	(button-props `(help-echo "Click to sort by column"
 			mouse-face header-line-highlight
 			keymap ,tabulated-list-sort-button-map))
+        (len (length tabulated-list-format))
 	(cols nil))
     (if display-line-numbers
         (setq x (+ x (tabulated-list-line-number-width))))
     (push (propertize " " 'display `(space :align-to ,x)) cols)
-    (dotimes (n (length tabulated-list-format))
+    (dotimes (n len)
       (let* ((col (aref tabulated-list-format n))
 	     (label (nth 0 col))
 	     (width (nth 1 col))
@@ -293,7 +294,11 @@ tabulated-list-init-header
 	   (apply 'propertize
 		  (concat label
 			  (cond
-			   ((> (+ 2 (length label)) width) "")
+			   ((and (> (+ 2 (length label)) width)
+                                 (not (= (tabulated-list--column-number
+                                          (car tabulated-list-sort-key))
+                                         (1- len))))
+                                 "")
 			   ((cdr tabulated-list-sort-key)
                             (format " %c"
                                     tabulated-list-gui-sort-indicator-desc))

But after I saw that final (rightmost) column in the problematic cases
was simply given too narrow a width, I thought it better to just change
that and clarify the doc.  But maybe you're right that the misleading
doc has affected third-party packages.

Steve Berman

Message #23 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 44068 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 00:18:23 +0200

On Sun, 18 Oct 2020 15:01:47 -0700 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Drew Adams <drew.adams <at> oracle.com> writes:
>
>> This rings a bell (maybe).  I think the sort-indicator
>> problem might be a duplicate bug report, but I can't
>> find the dup now.  There are some inherent problems
>> with the rightmost column, IIRC, that being one of them.
>
> Maybe Bug#41861?

Ah, thanks, I didn't see that.

Steve Berman

Message #26 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 00:35:38 +0200

On Mon, 19 Oct 2020 00:17:12 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Sun, 18 Oct 2020 15:01:31 -0700 Stefan Kangas <stefankangas <at> gmail.com> wrote:
[...]
>> Thanks for the patch.  I've tested it and it indeed fixes several bugs
>> in this area.
>>
>> But it got me thinking: for the final column at least, maybe we should
>> just make tabulated-list-mode work as advertised, and itself figure out
>> that it should use this length?  That way, we would solve any bugs also
>> for external packages that have been misled by the doc string.  Or would
>> that have any downsides?
>
> That was my first thought when I noticed the problem, and came up with
> this patch to fix it:
>
> diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
> index b13f609f88..d6bec72ade 100644
> --- a/lisp/emacs-lisp/tabulated-list.el
> +++ b/lisp/emacs-lisp/tabulated-list.el
> @@ -271,11 +271,12 @@ tabulated-list-init-header
>  	(button-props `(help-echo "Click to sort by column"
>  			mouse-face header-line-highlight
>  			keymap ,tabulated-list-sort-button-map))
> +        (len (length tabulated-list-format))
>  	(cols nil))
>      (if display-line-numbers
>          (setq x (+ x (tabulated-list-line-number-width))))
>      (push (propertize " " 'display `(space :align-to ,x)) cols)
> -    (dotimes (n (length tabulated-list-format))
> +    (dotimes (n len)
>        (let* ((col (aref tabulated-list-format n))
>  	     (label (nth 0 col))
>  	     (width (nth 1 col))
> @@ -293,7 +294,11 @@ tabulated-list-init-header
>  	   (apply 'propertize
>  		  (concat label
>  			  (cond
> -			   ((> (+ 2 (length label)) width) "")
> +			   ((and (> (+ 2 (length label)) width)
> +                                 (not (= (tabulated-list--column-number
> +                                          (car tabulated-list-sort-key))
> +                                         (1- len))))
> +                                 "")
>  			   ((cdr tabulated-list-sort-key)
>                              (format " %c"
>                                      tabulated-list-gui-sort-indicator-desc))
>
> But after I saw that final (rightmost) column in the problematic cases
> was simply given too narrow a width, I thought it better to just change
> that and clarify the doc.  But maybe you're right that the misleading
> doc has affected third-party packages.

I note, though, that this patch, won't fix too narrow non-final columns,
as the Archive column in package-menu-mode, or the Status column in
process-menu-mode, etc.

Steve Berman

Message #29 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Sun, 18 Oct 2020 16:13:54 -0700

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

> I note, though, that this patch, won't fix too narrow non-final columns,
> as the Archive column in package-menu-mode, or the Status column in
> process-menu-mode, etc.

Would it perhaps make sense to apply both these patches?

Message #32 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 11:04:02 +0200

On Sun, 18 Oct 2020 16:13:54 -0700 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I note, though, that this patch, won't fix too narrow non-final columns,
>> as the Archive column in package-menu-mode, or the Status column in
>> process-menu-mode, etc.
>
> Would it perhaps make sense to apply both these patches?

Since third-party packages may need to fix non-final column width in any
case (unless someone comes up with a patch that does it automatically),
the added complication of the patch for the final column seems less
compelling to me.

Steve Berman

Message #35 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 16:52:09 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Sun, 18 Oct 2020 22:00:13 +0200
> 
> On trying out the new tabulated-list implementation of the bookmarks
> list I noticed that, when clicking on the File header, the sort
> indicator is not displayed, unlike with the Bookmark header.  Then I
> noticed that the same thing happens in the tabulated buffer list (C-x
> C-b).  Then I grepped for all uses of tabulated-list-format in the Emacs
> sources and found the same problem in most of them.  The reason is that
> in these modes the width of at least one of the columns is too narrow,
> so that tabulated-list-init-header omits the indicator.  In most cases
> the problematic column is the final one, but in a couple of cases there
> are also non-final too narrow columns.  And I think these bugs are due
> to a misleading description in tabulated-list-format's doc string.  The
> attached patch corrects the doc string and the problematic uses of
> tabulated-list-format.  The patch also fixes a typo and tries to improve
> column alignment in timer-list-mode: this is one of the few modes
> derived from tabulated-list-mode whose column widths didn't need to be
> corrected, but the alignment seemed suboptimal; however, when the header
> line uses a variable-pitch face, the alignment is still suboptimal even
> with the patch, and I don't know how to fix that.

Instead of manually fine-tuning each column's width, wouldn't it be
better to use the string-trim capabilities that replace excess
characters with an ellipsis?

Thanks.

Message #38 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 20:20:16 +0200

On Mon, 19 Oct 2020 16:52:09 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Sun, 18 Oct 2020 22:00:13 +0200
>> 
>> On trying out the new tabulated-list implementation of the bookmarks
>> list I noticed that, when clicking on the File header, the sort
>> indicator is not displayed, unlike with the Bookmark header.  Then I
>> noticed that the same thing happens in the tabulated buffer list (C-x
>> C-b).  Then I grepped for all uses of tabulated-list-format in the Emacs
>> sources and found the same problem in most of them.  The reason is that
>> in these modes the width of at least one of the columns is too narrow,
>> so that tabulated-list-init-header omits the indicator.  In most cases
>> the problematic column is the final one, but in a couple of cases there
>> are also non-final too narrow columns.  And I think these bugs are due
>> to a misleading description in tabulated-list-format's doc string.  The
>> attached patch corrects the doc string and the problematic uses of
>> tabulated-list-format.  The patch also fixes a typo and tries to improve
>> column alignment in timer-list-mode: this is one of the few modes
>> derived from tabulated-list-mode whose column widths didn't need to be
>> corrected, but the alignment seemed suboptimal; however, when the header
>> line uses a variable-pitch face, the alignment is still suboptimal even
>> with the patch, and I don't know how to fix that.
>
> Instead of manually fine-tuning each column's width, wouldn't it be
> better to use the string-trim capabilities that replace excess
> characters with an ellipsis?

I'm not sure I understand your suggestion.  If you mean to truncate the
column label in the header line when displaying the sort indicator,
e.g. change "Status" to "Sta… ▼", I'm dubious it's worth the effort,
since most of the problematic cases in the Emacs sources are with the
final column, where there's always enough space, but due to the
misleading description in tabulated-list-format's doc string, many modes
have made it unnecessarily narrow, preventing the display of the sort
indicator.  So to avoid the final column being labelled e.g. either
"File" or "Fi… ▼" instead of "File ▼", it is necessary to change the
width manually anyway.  In other words, the truncation proposal would be
an addition to manual fine-tuning (for non-final columns), not a
substitute for it.  Or did you mean something else?

Steve Berman

Message #41 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 21:43:57 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 44068 <at> debbugs.gnu.org
> Date: Mon, 19 Oct 2020 20:20:16 +0200
> 
> > Instead of manually fine-tuning each column's width, wouldn't it be
> > better to use the string-trim capabilities that replace excess
> > characters with an ellipsis?
> 
> I'm not sure I understand your suggestion.  If you mean to truncate the
> column label in the header line when displaying the sort indicator,
> e.g. change "Status" to "Sta… ▼", I'm dubious it's worth the effort,
> since most of the problematic cases in the Emacs sources are with the
> final column, where there's always enough space, but due to the
> misleading description in tabulated-list-format's doc string, many modes
> have made it unnecessarily narrow, preventing the display of the sort
> indicator.  So to avoid the final column being labelled e.g. either
> "File" or "Fi… ▼" instead of "File ▼", it is necessary to change the
> width manually anyway.  In other words, the truncation proposal would be
> an addition to manual fine-tuning (for non-final columns), not a
> substitute for it.  Or did you mean something else?

Yes, I meant it as an addition, which will make this issue much more
future proof.  Documentation update is definitely fine (and should
probably go to emacs-27, not to master, right?), and adjusting the
column widths to eliminate the ellipsis is also okay.  I just don't
want us to end with these two and nothing else.

Message #44 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 19 Oct 2020 21:12:44 +0200

On Mon, 19 Oct 2020 21:43:57 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 44068 <at> debbugs.gnu.org
>> Date: Mon, 19 Oct 2020 20:20:16 +0200
>> 
>> > Instead of manually fine-tuning each column's width, wouldn't it be
>> > better to use the string-trim capabilities that replace excess
>> > characters with an ellipsis?
>> 
>> I'm not sure I understand your suggestion.  If you mean to truncate the
>> column label in the header line when displaying the sort indicator,
>> e.g. change "Status" to "Sta… ▼", I'm dubious it's worth the effort,
>> since most of the problematic cases in the Emacs sources are with the
>> final column, where there's always enough space, but due to the
>> misleading description in tabulated-list-format's doc string, many modes
>> have made it unnecessarily narrow, preventing the display of the sort
>> indicator.  So to avoid the final column being labelled e.g. either
>> "File" or "Fi… ▼" instead of "File ▼", it is necessary to change the
>> width manually anyway.  In other words, the truncation proposal would be
>> an addition to manual fine-tuning (for non-final columns), not a
>> substitute for it.  Or did you mean something else?
>
> Yes, I meant it as an addition, which will make this issue much more
> future proof.  Documentation update is definitely fine (and should
> probably go to emacs-27, not to master, right?), and adjusting the
> column widths to eliminate the ellipsis is also okay.  I just don't
> want us to end with these two and nothing else.

Ok.  I can try, but anyone should feel free to beat me to it.

Steve Berman

Message #47 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Tue, 20 Oct 2020 18:09:56 +0200

[Message part 1 (text/plain, inline)]

On Mon, 19 Oct 2020 21:12:44 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Mon, 19 Oct 2020 21:43:57 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman <at> gmx.net>
>>> Cc: 44068 <at> debbugs.gnu.org
>>> Date: Mon, 19 Oct 2020 20:20:16 +0200
>>> 
>>> > Instead of manually fine-tuning each column's width, wouldn't it be
>>> > better to use the string-trim capabilities that replace excess
>>> > characters with an ellipsis?
>>> 
>>> I'm not sure I understand your suggestion.  If you mean to truncate the
>>> column label in the header line when displaying the sort indicator,
>>> e.g. change "Status" to "Sta… ▼", I'm dubious it's worth the effort,
>>> since most of the problematic cases in the Emacs sources are with the
>>> final column, where there's always enough space, but due to the
>>> misleading description in tabulated-list-format's doc string, many modes
>>> have made it unnecessarily narrow, preventing the display of the sort
>>> indicator.  So to avoid the final column being labelled e.g. either
>>> "File" or "Fi… ▼" instead of "File ▼", it is necessary to change the
>>> width manually anyway.  In other words, the truncation proposal would be
>>> an addition to manual fine-tuning (for non-final columns), not a
>>> substitute for it.  Or did you mean something else?
>>
>> Yes, I meant it as an addition, which will make this issue much more
>> future proof.  Documentation update is definitely fine (and should
>> probably go to emacs-27, not to master, right?), and adjusting the
>> column widths to eliminate the ellipsis is also okay.  I just don't
>> want us to end with these two and nothing else.
>
> Ok.  I can try, but anyone should feel free to beat me to it.

I was wrong that adjusting column widths in tabulated-list-format is
necessary: with the attached patch, when a non-final column whose label
is at least 3 characters long is selected, the label will get truncated
and a sort indicator added; but the final column label will never get
truncated and always get a sort indicator when selected.  The question
remains whether the truncated display in current (non-adjusted) uses of
tabulated-list-mode is acceptable: if so, the patch below is all that's
needed, if not, then the adjustments in my first patch can be made as
well.  Those interested should try the patch with list-buffers,
list-bookmarks, list-packages, list-processes, list-dynamic-libraries,
org-lint and flymake-diagnostics-buffer-mode to see how the display
looks.  Depending on the decision about that, the doc string of
tabulated-list-format should be reworked accordingly.

Steve Berman

[Message part 2 (text/x-patch, attachment)]

Message #50 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Thu, 29 Oct 2020 16:58:52 +0000

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

> I was wrong that adjusting column widths in tabulated-list-format is
> necessary: with the attached patch, when a non-final column whose label
> is at least 3 characters long is selected, the label will get truncated
> and a sort indicator added; but the final column label will never get
> truncated and always get a sort indicator when selected.

The behavior with your patch looks like an improvement to me.  How about
the case when we narrow the column but there is no sort indicator,
should we use the ellipsis then?  See for example `list-buffers' when
using the narrowing commands without sorting on any of the headers.

> The question remains whether the truncated display in current
> (non-adjusted) uses of tabulated-list-mode is acceptable: if so, the
> patch below is all that's needed, if not, then the adjustments in my
> first patch can be made as well.

I'm not sure I understand what you mean here, could you elaborate?

Message #53 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Thu, 29 Oct 2020 23:48:38 +0100

[Message part 1 (text/plain, inline)]

On Thu, 29 Oct 2020 16:58:52 +0000 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> I was wrong that adjusting column widths in tabulated-list-format is
>> necessary: with the attached patch, when a non-final column whose label
>> is at least 3 characters long is selected, the label will get truncated
>> and a sort indicator added; but the final column label will never get
>> truncated and always get a sort indicator when selected.
>
> The behavior with your patch looks like an improvement to me.  How about
> the case when we narrow the column but there is no sort indicator,
> should we use the ellipsis then?  See for example `list-buffers' when
> using the narrowing commands without sorting on any of the headers.

Try the attached patch; does it do what you're suggesting well enough?

[Message part 2 (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

>> The question remains whether the truncated display in current
>> (non-adjusted) uses of tabulated-list-mode is acceptable: if so, the
>> patch below is all that's needed, if not, then the adjustments in my
>> first patch can be made as well.
>
> I'm not sure I understand what you mean here, could you elaborate?

I meant that in some uses of tabulated-list-mode there are columns whose
default width is so narrow that, when selected for sorting, they are
immediately truncated (using the patch in my previous post), e.g. the
"Status" column in list-processes.  And the issue is exacerbated with
the current patch implementing your new suggestion: with its default
width "Status" is now truncated whether selected or not.  In such cases
it may be better to make the default width of such columns wider, which
is what my first patch did.  Then with the current patch, it will still
be truncated when the column is sufficiently narrowed with `{'.

Steve Berman

Message #56 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Thu, 29 Oct 2020 18:06:16 -0700

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

> Try the attached patch; does it do what you're suggesting well enough?

Yes, it looks better.

> I meant that in some uses of tabulated-list-mode there are columns whose
> default width is so narrow that, when selected for sorting, they are
> immediately truncated (using the patch in my previous post), e.g. the
> "Status" column in list-processes.  And the issue is exacerbated with
> the current patch implementing your new suggestion: with its default
> width "Status" is now truncated whether selected or not.

But the "Status" field in process-menu-mode is 7, so why is it
truncated when there is room?  "Status" is only 6 characters.

I would expect that "Status" was not truncated in this case, IOW that:

- Without a sorting indicator
   - label width <= column width  => display it all
   - label width >  column width  => truncate

- With a sorting indicator
   - label width <= column width  => display it all
   - label width >  column width  => truncate

For the last column, we should probably just show it all regardless of
its width, and never truncate.

Does the above make sense?

BTW, perhaps we should add unit tests for all this, since it seems like
we have a fair amount of use-cases to think about.  Maybe that could be
a good excuse to make tabulated-list-init-header a bit more functional...

> In such cases it may be better to make the default width of such
> columns wider, which is what my first patch did.  Then with the
> current patch, it will still be truncated when the column is
> sufficiently narrowed with `{'.

Yes, the default width of such columns should also be made wider, I
think.  But first we should probably make sure that the underlying logic
here is sound.

Thanks again for working on this.

Message #59 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stephen Berman <stephen.berman <at> gmx.net>,
 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Fri, 30 Oct 2020 22:44:48 +0100

[Message part 1 (text/plain, inline)]

On Thu, 29 Oct 2020 18:06:16 -0700 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> Try the attached patch; does it do what you're suggesting well enough?
>
> Yes, it looks better.
>
>> I meant that in some uses of tabulated-list-mode there are columns whose
>> default width is so narrow that, when selected for sorting, they are
>> immediately truncated (using the patch in my previous post), e.g. the
>> "Status" column in list-processes.  And the issue is exacerbated with
>> the current patch implementing your new suggestion: with its default
>> width "Status" is now truncated whether selected or not.
>
> But the "Status" field in process-menu-mode is 7, so why is it
> truncated when there is room?  "Status" is only 6 characters.
>
> I would expect that "Status" was not truncated in this case, IOW that:
>
> - Without a sorting indicator
>    - label width <= column width  => display it all
>    - label width >  column width  => truncate
>
> - With a sorting indicator
>    - label width <= column width  => display it all
>    - label width >  column width  => truncate
>
> For the last column, we should probably just show it all regardless of
> its width, and never truncate.
>
> Does the above make sense?

It seems to.  I did experiment a bit with the width when I made the
patch just for the selected column and thought the length I used there
gave the best results, but maybe that was too cautious.  Does this patch
give better results (it differs from the previous one only in the
lengths checked and used for truncating):

[Message part 2 (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

It might be better to take more width parameters into account, as
tabulated-list-print-col does, but that seems rather more complicated
and I currently don't have time to pursue it.

> BTW, perhaps we should add unit tests for all this, since it seems like
> we have a fair amount of use-cases to think about.  Maybe that could be
> a good excuse to make tabulated-list-init-header a bit more functional...

For sure (but again, I currently don't have time for that).

>> In such cases it may be better to make the default width of such
>> columns wider, which is what my first patch did.  Then with the
>> current patch, it will still be truncated when the column is
>> sufficiently narrowed with `{'.
>
> Yes, the default width of such columns should also be made wider, I
> think.  But first we should probably make sure that the underlying logic
> here is sound.

I agree

> Thanks again for working on this.

I wish I had more time for it but at the moment I don't.

Steve Berman

Message #62 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Fri, 30 Oct 2020 23:51:21 +0000

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

> It seems to.  I did experiment a bit with the width when I made the
> patch just for the selected column and thought the length I used there
> gave the best results, but maybe that was too cautious.  Does this patch
> give better results (it differs from the previous one only in the
> lengths checked and used for truncating):

I think this looks very good, yes.  It works fully as I would expect, at
least: it seems to always correctly show the sorting indicator and the
ellipsis.

(I tested using list-buffers, list-bookmarks, list-packages,
list-processes, list-dynamic-libraries, org-lint and
flymake-diagnostics-buffer-mode.)

Perhaps we could just go over the list above as you did in your first
patch and make sure that there is enough space for all of these to show
a sorting indicator without it touching the next column label.

> It might be better to take more width parameters into account, as
> tabulated-list-print-col does, but that seems rather more complicated
> and I currently don't have time to pursue it.

I imagine we can come back to and improve on this later.

> I wish I had more time for it but at the moment I don't.

What you have here is already a big improvement, thank you.

I would recommend to push this to master.

Message #65 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 02 Nov 2020 00:07:34 +0100

On Fri, 30 Oct 2020 23:51:21 +0000 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> It seems to.  I did experiment a bit with the width when I made the
>> patch just for the selected column and thought the length I used there
>> gave the best results, but maybe that was too cautious.  Does this patch
>> give better results (it differs from the previous one only in the
>> lengths checked and used for truncating):
>
> I think this looks very good, yes.  It works fully as I would expect, at
> least: it seems to always correctly show the sorting indicator and the
> ellipsis.
>
> (I tested using list-buffers, list-bookmarks, list-packages,
> list-processes, list-dynamic-libraries, org-lint and
> flymake-diagnostics-buffer-mode.)

Thanks for testing.

> Perhaps we could just go over the list above as you did in your first
> patch and make sure that there is enough space for all of these to show
> a sorting indicator without it touching the next column label.

I'll try to do that soon, but feel free to beat me to it ;-)

As an aside, do you think that use of the :right-align :pad-right
properties in timer-list-mode in my first patch is a good change?

>> It might be better to take more width parameters into account, as
>> tabulated-list-print-col does, but that seems rather more complicated
>> and I currently don't have time to pursue it.
>
> I imagine we can come back to and improve on this later.

Sure.

>> I wish I had more time for it but at the moment I don't.
>
> What you have here is already a big improvement, thank you.
>
> I would recommend to push this to master.

Thanks.  Eli, is that ok with you?

Steve Berman

Message #68 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: stefankangas <at> gmail.com, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 02 Nov 2020 19:12:16 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44068 <at> debbugs.gnu.org
> Date: Mon, 02 Nov 2020 00:07:34 +0100
> 
> > What you have here is already a big improvement, thank you.
> >
> > I would recommend to push this to master.
> 
> Thanks.  Eli, is that ok with you?

Any reason I might not be okay with it?  (I cannot say I've read every
message in this thread to the last word.)

Message #71 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefankangas <at> gmail.com, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Mon, 02 Nov 2020 23:37:57 +0100

On Mon, 02 Nov 2020 19:12:16 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>,  44068 <at> debbugs.gnu.org
>> Date: Mon, 02 Nov 2020 00:07:34 +0100
>>
>> > What you have here is already a big improvement, thank you.
>> >
>> > I would recommend to push this to master.
>>
>> Thanks.  Eli, is that ok with you?
>
> Any reason I might not be okay with it?

I hope not ;-).

>                                          (I cannot say I've read every
> message in this thread to the last word.)

Assuming the patch doesn't introduce a bug, it's essentially a question
of aesthetics, and since Stefan K said it looks good to him, that's good
enough for me, but since you asked for such a change upthread
<83zh4ipbli.fsf <at> gnu.org>, I wanted to make sure you also accept the
result.

Steve Berman

Message #74 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: stefankangas <at> gmail.com, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Tue, 03 Nov 2020 05:27:30 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: stefankangas <at> gmail.com,  44068 <at> debbugs.gnu.org
> Date: Mon, 02 Nov 2020 23:37:57 +0100
> 
> >> Thanks.  Eli, is that ok with you?
> >
> > Any reason I might not be okay with it?
> 
> I hope not ;-).
> 
> >                                          (I cannot say I've read every
> > message in this thread to the last word.)
> 
> Assuming the patch doesn't introduce a bug, it's essentially a question
> of aesthetics, and since Stefan K said it looks good to him, that's good
> enough for me, but since you asked for such a change upthread
> <83zh4ipbli.fsf <at> gnu.org>, I wanted to make sure you also accept the
> result.

Can you describe the result?  I don't think I have a clear idea what
it will be.

Thanks.

Message #77 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefankangas <at> gmail.com, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Wed, 04 Nov 2020 00:12:31 +0100

On Tue, 03 Nov 2020 05:27:30 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: stefankangas <at> gmail.com,  44068 <at> debbugs.gnu.org
>> Date: Mon, 02 Nov 2020 23:37:57 +0100
[...]
>> Assuming the patch doesn't introduce a bug, it's essentially a question
>> of aesthetics, and since Stefan K said it looks good to him, that's good
>> enough for me, but since you asked for such a change upthread
>> <83zh4ipbli.fsf <at> gnu.org>, I wanted to make sure you also accept the
>> result.
>
> Can you describe the result?  I don't think I have a clear idea what
> it will be.

There are two features the patch provides:

- All sortable columns in tabulated-list-mode derivatives that are wide
  enough to display a sort indicator when selected do so (sortable
  columns that are not wide enough include e.g. the first three in the
  Buffer-menu-mode table).  In contrast, currently, i.e. without the
  patch, all final sortable columns and some non-final ones that are
  wide enough do not display the sort indicator when selected.

- When a column (whether selected or not) is made narrower (by
  repeatedly typing `{') than the length of the column label in the
  header line, the label is truncated and displays a trailing ellipis,
  just like the data lines of such columns in the table (if such a
  narrowed column is sortable and selected, the the sort indicator is
  still displayed after the ellipis).  In contrast, currently, the
  column labels are not truncated, which can lead to misalignment
  between the header line and the data lines.  (However, even with the
  patch, misalignment can happen, because the data lines can be
  truncated to display nothing but the ellipis, while the header line
  labels always show at least the first letter of the label.  I think
  the display of the data lines here is questionable, but dealing with
  that is another issue.)

Steve Berman

Message #80 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Wed, 4 Nov 2020 04:02:04 -0800

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

> As an aside, do you think that use of the :right-align :pad-right
> properties in timer-list-mode in my first patch is a good change?

Do you mean this part?

-          ("      Next" 12 timer-list--next-predicate)
-          ("  Repeat" 11 timer-list--repeat-predicate)
+          ("Next" 12 timer-list--next-predicate :right-align t :pad-right 1)
+          ("Repeat" 11 timer-list--repeat-predicate :right-align t
:pad-right 1)

If so, it definitely looks like an improvement to me.  Do you see any
problems with it?

BTW, does it work better with narrowing the column, too?  We seem to
have some issues with that currently.

Message #87 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: stefankangas <at> gmail.com, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Wed, 04 Nov 2020 17:09:30 +0200

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: stefankangas <at> gmail.com,  44068 <at> debbugs.gnu.org
> Date: Wed, 04 Nov 2020 00:12:31 +0100
> 
> > Can you describe the result?  I don't think I have a clear idea what
> > it will be.
> 
> There are two features the patch provides:
> 
> - All sortable columns in tabulated-list-mode derivatives that are wide
>   enough to display a sort indicator when selected do so (sortable
>   columns that are not wide enough include e.g. the first three in the
>   Buffer-menu-mode table).  In contrast, currently, i.e. without the
>   patch, all final sortable columns and some non-final ones that are
>   wide enough do not display the sort indicator when selected.
> 
> - When a column (whether selected or not) is made narrower (by
>   repeatedly typing `{') than the length of the column label in the
>   header line, the label is truncated and displays a trailing ellipis,
>   just like the data lines of such columns in the table (if such a
>   narrowed column is sortable and selected, the the sort indicator is
>   still displayed after the ellipis).  In contrast, currently, the
>   column labels are not truncated, which can lead to misalignment
>   between the header line and the data lines.  (However, even with the
>   patch, misalignment can happen, because the data lines can be
>   truncated to display nothing but the ellipis, while the header line
>   labels always show at least the first letter of the label.  I think
>   the display of the data lines here is questionable, but dealing with
>   that is another issue.)

Sound like good improvements, thanks.

Message #90 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Wed, 04 Nov 2020 23:53:56 +0100

On Wed, 4 Nov 2020 04:02:04 -0800 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> As an aside, do you think that use of the :right-align :pad-right
>> properties in timer-list-mode in my first patch is a good change?
>
> Do you mean this part?
>
> -          ("      Next" 12 timer-list--next-predicate)
> -          ("  Repeat" 11 timer-list--repeat-predicate)
> +          ("Next" 12 timer-list--next-predicate :right-align t :pad-right 1)
> +          ("Repeat" 11 timer-list--repeat-predicate :right-align t
> :pad-right 1)
>
> If so, it definitely looks like an improvement to me.  Do you see any
> problems with it?

No, and in fact without it the tabulated-list-init-header patch makes
selecting "Repeat" column (and hence displaying the sort indicator
there) push the "Function" column label to the right, causing
misalignment with the data lines; with the properties this does not
happen.  (However, the width of 11 makes the data lines of the "Repeat"
column appear truncated, but this width was changed to 12 in commit
0cb44eed6, fixing that problem.)

> BTW, does it work better with narrowing the column, too?  We seem to
> have some issues with that currently.

Do you mean that truncation happens even though there is still enough
space to display the data or header?  I see that both with hard spaces
and with the :right-align property.  I haven't tried to figure out why
that's happening, but seems to be separate from above change.

Given that, and also Eli's approval of the tabulated-list-init-header
patch, I've gone ahead and committed these changes.  I didn't make any
of the column width changes I proposed in my first patch, since with the
tabulated-list-init-header patch they don't seem to be needed.
Nevertheless, there's clearly still room for improvement, in particular
concerning truncation (I also hinted at another problem with this in my
last reply to Eli).

Steve Berman

Message #93 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefankangas <at> gmail.com, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Wed, 04 Nov 2020 23:55:12 +0100

On Wed, 04 Nov 2020 17:09:30 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: stefankangas <at> gmail.com,  44068 <at> debbugs.gnu.org
>> Date: Wed, 04 Nov 2020 00:12:31 +0100
>>
>> > Can you describe the result?  I don't think I have a clear idea what
>> > it will be.
>>
>> There are two features the patch provides:
>>
>> - All sortable columns in tabulated-list-mode derivatives that are wide
>>   enough to display a sort indicator when selected do so (sortable
>>   columns that are not wide enough include e.g. the first three in the
>>   Buffer-menu-mode table).  In contrast, currently, i.e. without the
>>   patch, all final sortable columns and some non-final ones that are
>>   wide enough do not display the sort indicator when selected.
>>
>> - When a column (whether selected or not) is made narrower (by
>>   repeatedly typing `{') than the length of the column label in the
>>   header line, the label is truncated and displays a trailing ellipis,
>>   just like the data lines of such columns in the table (if such a
>>   narrowed column is sortable and selected, the the sort indicator is
>>   still displayed after the ellipis).  In contrast, currently, the
>>   column labels are not truncated, which can lead to misalignment
>>   between the header line and the data lines.  (However, even with the
>>   patch, misalignment can happen, because the data lines can be
>>   truncated to display nothing but the ellipis, while the header line
>>   labels always show at least the first letter of the label.  I think
>>   the display of the data lines here is questionable, but dealing with
>>   that is another issue.)
>
> Sound like good improvements, thanks.

Thanks, I've pushed it to master in commit 233d350d19.

Steve Berman

Message #96 received at 44068 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068 <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Thu, 12 Nov 2020 11:38:04 -0500

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

>> BTW, does it work better with narrowing the column, too?  We seem to
>> have some issues with that currently.
>
> Do you mean that truncation happens even though there is still enough
> space to display the data or header?  I see that both with hard spaces
> and with the :right-align property.  I haven't tried to figure out why
> that's happening, but seems to be separate from above change.

Indeed, it is a separate issue.  I have opened Bug#44594 to track it.

> Given that, and also Eli's approval of the tabulated-list-init-header
> patch, I've gone ahead and committed these changes.  I didn't make any
> of the column width changes I proposed in my first patch, since with the
> tabulated-list-init-header patch they don't seem to be needed.

Thank you!  I guess this bug should therefore be closed as fixed?

Message #101 received at 44068-done <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 44068-done <at> debbugs.gnu.org
Subject: Re: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Thu, 12 Nov 2020 23:51:40 +0100

On Thu, 12 Nov 2020 11:38:04 -0500 Stefan Kangas <stefankangas <at> gmail.com> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>>> BTW, does it work better with narrowing the column, too?  We seem to
>>> have some issues with that currently.
>>
>> Do you mean that truncation happens even though there is still enough
>> space to display the data or header?  I see that both with hard spaces
>> and with the :right-align property.  I haven't tried to figure out why
>> that's happening, but seems to be separate from above change.
>
> Indeed, it is a separate issue.  I have opened Bug#44594 to track it.

Thanks.

>> Given that, and also Eli's approval of the tabulated-list-init-header
>> patch, I've gone ahead and committed these changes.  I didn't make any
>> of the column width changes I proposed in my first patch, since with the
>> tabulated-list-init-header patch they don't seem to be needed.
>
> Thank you!  I guess this bug should therefore be closed as fixed?

Yeah, I forgot to do that after committing the patch, done now.

Steve Berman

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.