* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
@ 2020-10-18 20:00 Stephen Berman
2020-10-18 21:33 ` Drew Adams
` (2 more replies)
0 siblings, 3 replies; 31+ messages in thread
From: Stephen Berman @ 2020-10-18 20:00 UTC (permalink / raw)
To: 44068
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]
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@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.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Fix uses of tabulated-list-format --]
[-- Type: text/x-patch, Size: 7258 bytes --]
diff --git a/lisp/bookmark.el b/lisp/bookmark.el
index ab7b04ddfe..f37f0b0ce9 100644
--- a/lisp/bookmark.el
+++ b/lisp/bookmark.el
@@ -1783,7 +1783,7 @@ bookmark-bmenu-mode
`[("" 1) ;; Space to add "*" for bookmark with annotation
("Bookmark" ,bookmark-bmenu-file-column bookmark-bmenu--name-predicate)
,@(if bookmark-bmenu-toggle-filenames
- '(("File" 0 bookmark-bmenu--file-predicate)))])
+ '(("File" 6 bookmark-bmenu--file-predicate)))])
(setq tabulated-list-padding bookmark-bmenu-marks-width)
(setq tabulated-list-sort-key '("Bookmark" . nil))
(add-hook 'tabulated-list-revert-hook #'bookmark-bmenu--revert nil t)'
diff --git a/lisp/buff-menu.el b/lisp/buff-menu.el
index d06ba28787..5cf13cb50f 100644
--- a/lisp/buff-menu.el
+++ b/lisp/buff-menu.el
@@ -706,7 +706,7 @@ list-buffers--refresh
`("Size" ,size-width tabulated-list-entry-size->
:right-align t)
`("Mode" ,Buffer-menu-mode-width t)
- '("File" 1 t)))
+ '("File" 6 t)))
(setq tabulated-list-use-header-line Buffer-menu-use-header-line)
(setq tabulated-list-entries (nreverse entries)))
(tabulated-list-init-header))
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index 7b192d640b..32b99367c3 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -412,7 +412,7 @@ package-status-column-width
:type 'number
:version "28.1")
-(defcustom package-archive-column-width 8
+(defcustom package-archive-column-width 9
"Column width for the Package status in the package menu."
:type 'number
:version "28.1")
@@ -2770,7 +2770,7 @@ package-menu-mode
("Status" ,package-status-column-width package-menu--status-predicate)
,@(if (cdr package-archives)
`(("Archive" ,package-archive-column-width package-menu--archive-predicate)))
- ("Description" 0 package-menu--description-predicate)])
+ ("Description" 13 package-menu--description-predicate)])
(setq tabulated-list-padding 2)
(setq tabulated-list-sort-key (cons "Status" nil))
(add-hook 'tabulated-list-revert-hook #'package-menu--refresh nil t)
diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
index b13f609f88..20e43d9c4a 100644
--- a/lisp/emacs-lisp/tabulated-list.el
+++ b/lisp/emacs-lisp/tabulated-list.el
@@ -91,7 +91,9 @@ tabulated-list-format
This is the label for the column in the header line.
Different columns must have non-`equal' names.
- WIDTH is the width to reserve for the column.
- For the final element, its numerical value is ignored.
+ Its value must be at least 2 more than the length of NAME
+ in order to display the column's sort indicator.
+ Not used for computing the width of the final element.
- SORT specifies how to sort entries by this column.
If nil, this column cannot be used for sorting.
If t, sort by comparing the string value printed in the column.
diff --git a/lisp/emacs-lisp/timer-list.el b/lisp/emacs-lisp/timer-list.el
index 00d09696d2..afcd7d3354 100644
--- a/lisp/emacs-lisp/timer-list.el
+++ b/lisp/emacs-lisp/timer-list.el
@@ -93,8 +93,8 @@ timer-list-mode
(setq-local revert-buffer-function #'list-timers)
(setq tabulated-list-format
'[("Idle" 6 timer-list--idle-predicate)
- (" 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)
("Function" 10 timer-list--function-predicate)]))
(defun timer-list--idle-predicate (A B)
@@ -119,7 +119,7 @@ timer-list--repeat-predicate
(string< rA rB)))
(defun timer-list--function-predicate (A B)
- "Predicate to sort Timer-List by the Next column."
+ "Predicate to sort Timer-List by the Function column."
(let ((fA (aref (cadr A) 3))
(fB (aref (cadr B) 3)))
(string< fA fB)))
diff --git a/lisp/misc.el b/lisp/misc.el
index be191c50d2..b65f56efc3 100644
--- a/lisp/misc.el
+++ b/lisp/misc.el
@@ -170,9 +170,9 @@ list-dynamic-libraries--refresh
(name-len (apply 'max (mapcar 'length (cdr lib)))))
(when (> id-len max-id-len) (setq max-id-len id-len))
(when (> name-len max-name-len) (setq max-name-len name-len))))
- (vector (list "Library" (1+ max-id-len) t)
- (list "Loaded from" (1+ max-name-len) t)
- (list "Candidate names" 0 t))))
+ (vector (list "Library" (+ max-id-len 2) t)
+ (list "Loaded from" (+ max-name-len 2) t)
+ (list "Candidate names" 17 t))))
(tabulated-list-init-header)
(setq tabulated-list-entries nil)
(dolist (lib dynamic-library-alist)
diff --git a/lisp/org/org-lint.el b/lisp/org/org-lint.el
index 5be1ec7286..0c3eca7998 100644
--- a/lisp/org/org-lint.el
+++ b/lisp/org/org-lint.el
@@ -1089,8 +1089,8 @@ org-lint--report-mode
(< (string-to-number (aref (cadr a) 0))
(string-to-number (aref (cadr b) 0))))
:right-align t)
- ("Trust" 5 t)
- ("Warning" 0 t)])
+ ("Trust" 7 t)
+ ("Warning" 9 t)])
(tabulated-list-init-header))
(defun org-lint--generate-reports (buffer checkers)
diff --git a/lisp/progmodes/flymake.el b/lisp/progmodes/flymake.el
index b286208fff..602e8f2609 100644
--- a/lisp/progmodes/flymake.el
+++ b/lisp/progmodes/flymake.el
@@ -1376,7 +1376,7 @@ flymake-diagnostics-buffer-mode
"Flymake diagnostics"
"A mode for listing Flymake diagnostics."
(setq tabulated-list-format
- `[("Line" 5 ,(lambda (l1 l2)
+ `[("Line" 6 ,(lambda (l1 l2)
(< (plist-get (car l1) :line)
(plist-get (car l2) :line)))
:right-align t)
@@ -1384,7 +1384,7 @@ flymake-diagnostics-buffer-mode
("Type" 8 ,(lambda (l1 l2)
(< (plist-get (car l1) :severity)
(plist-get (car l2) :severity))))
- ("Message" 0 t)])
+ ("Message" 9 t)])
(setq tabulated-list-entries
'flymake--diagnostics-buffer-entries)
(tabulated-list-init-header))
diff --git a/lisp/simple.el b/lisp/simple.el
index d6fce922c4..b34450aeb5 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -4388,13 +4388,13 @@ process-menu-mode
"Major mode for listing the processes called by Emacs."
(setq tabulated-list-format [("Process" 15 t)
("PID" 7 t)
- ("Status" 7 t)
+ ("Status" 8 t)
;; 25 is the length of the long standard buffer
;; name "*Async Shell Command*<10>" (bug#30016)
("Buffer" 25 t)
("TTY" 12 t)
("Thread" 12 t)
- ("Command" 0 t)])
+ ("Command" 9 t)])
(make-local-variable 'process-menu-query-only)
(setq tabulated-list-sort-key (cons "Process" nil))
(add-hook 'tabulated-list-revert-hook 'list-processes--refresh nil t))
^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 20:00 bug#44068: 28.0.50; Faulty uses of tabulated-list-format Stephen Berman
@ 2020-10-18 21:33 ` Drew Adams
2020-10-18 22:01 ` Stefan Kangas
2020-10-18 22:01 ` Stefan Kangas
2020-10-19 13:52 ` Eli Zaretskii
2 siblings, 1 reply; 31+ messages in thread
From: Drew Adams @ 2020-10-18 21:33 UTC (permalink / raw)
To: Stephen Berman, 44068
> 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.)
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 20:00 bug#44068: 28.0.50; Faulty uses of tabulated-list-format Stephen Berman
2020-10-18 21:33 ` Drew Adams
@ 2020-10-18 22:01 ` Stefan Kangas
2020-10-18 22:17 ` Stephen Berman
2020-10-19 13:52 ` Eli Zaretskii
2 siblings, 1 reply; 31+ messages in thread
From: Stefan Kangas @ 2020-10-18 22:01 UTC (permalink / raw)
To: Stephen Berman, 44068
Stephen Berman <stephen.berman@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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 21:33 ` Drew Adams
@ 2020-10-18 22:01 ` Stefan Kangas
2020-10-18 22:15 ` Drew Adams
2020-10-18 22:18 ` Stephen Berman
0 siblings, 2 replies; 31+ messages in thread
From: Stefan Kangas @ 2020-10-18 22:01 UTC (permalink / raw)
To: Drew Adams, Stephen Berman, 44068
Drew Adams <drew.adams@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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 22:01 ` Stefan Kangas
@ 2020-10-18 22:15 ` Drew Adams
2020-10-18 22:18 ` Stephen Berman
1 sibling, 0 replies; 31+ messages in thread
From: Drew Adams @ 2020-10-18 22:15 UTC (permalink / raw)
To: Stefan Kangas, Stephen Berman, 44068
> > 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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 22:01 ` Stefan Kangas
@ 2020-10-18 22:17 ` Stephen Berman
2020-10-18 22:35 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-10-18 22:17 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068
On Sun, 18 Oct 2020 15:01:31 -0700 Stefan Kangas <stefankangas@gmail.com> wrote:
> Stephen Berman <stephen.berman@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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 22:01 ` Stefan Kangas
2020-10-18 22:15 ` Drew Adams
@ 2020-10-18 22:18 ` Stephen Berman
1 sibling, 0 replies; 31+ messages in thread
From: Stephen Berman @ 2020-10-18 22:18 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068
On Sun, 18 Oct 2020 15:01:47 -0700 Stefan Kangas <stefankangas@gmail.com> wrote:
> Drew Adams <drew.adams@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 22:17 ` Stephen Berman
@ 2020-10-18 22:35 ` Stephen Berman
2020-10-18 23:13 ` Stefan Kangas
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-10-18 22:35 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068
On Mon, 19 Oct 2020 00:17:12 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
> On Sun, 18 Oct 2020 15:01:31 -0700 Stefan Kangas <stefankangas@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 22:35 ` Stephen Berman
@ 2020-10-18 23:13 ` Stefan Kangas
2020-10-19 9:04 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Stefan Kangas @ 2020-10-18 23:13 UTC (permalink / raw)
To: Stephen Berman; +Cc: 44068
Stephen Berman <stephen.berman@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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 23:13 ` Stefan Kangas
@ 2020-10-19 9:04 ` Stephen Berman
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Berman @ 2020-10-19 9:04 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068
On Sun, 18 Oct 2020 16:13:54 -0700 Stefan Kangas <stefankangas@gmail.com> wrote:
> Stephen Berman <stephen.berman@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-18 20:00 bug#44068: 28.0.50; Faulty uses of tabulated-list-format Stephen Berman
2020-10-18 21:33 ` Drew Adams
2020-10-18 22:01 ` Stefan Kangas
@ 2020-10-19 13:52 ` Eli Zaretskii
2020-10-19 18:20 ` Stephen Berman
2 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2020-10-19 13:52 UTC (permalink / raw)
To: Stephen Berman; +Cc: 44068
> From: Stephen Berman <stephen.berman@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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-19 13:52 ` Eli Zaretskii
@ 2020-10-19 18:20 ` Stephen Berman
2020-10-19 18:43 ` Eli Zaretskii
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-10-19 18:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44068
On Mon, 19 Oct 2020 16:52:09 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-19 18:20 ` Stephen Berman
@ 2020-10-19 18:43 ` Eli Zaretskii
2020-10-19 19:12 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2020-10-19 18:43 UTC (permalink / raw)
To: Stephen Berman; +Cc: 44068
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 44068@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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-19 18:43 ` Eli Zaretskii
@ 2020-10-19 19:12 ` Stephen Berman
2020-10-20 16:09 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-10-19 19:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44068
On Mon, 19 Oct 2020 21:43:57 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 44068@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-19 19:12 ` Stephen Berman
@ 2020-10-20 16:09 ` Stephen Berman
2020-10-29 16:58 ` Stefan Kangas
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-10-20 16:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 44068
[-- Attachment #1: Type: text/plain, Size: 2696 bytes --]
On Mon, 19 Oct 2020 21:12:44 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
> On Mon, 19 Oct 2020 21:43:57 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: 44068@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
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tabulated-list-init-header patch --]
[-- Type: text/x-patch, Size: 2883 bytes --]
diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
index b13f609f88..aff7f985b9 100644
--- a/lisp/emacs-lisp/tabulated-list.el
+++ b/lisp/emacs-lisp/tabulated-list.el
@@ -269,15 +269,18 @@ tabulated-list-init-header
;; FIXME: Should share code with tabulated-list-print-col!
(let ((x (max tabulated-list-padding 0))
(button-props `(help-echo "Click to sort by column"
- mouse-face header-line-highlight
- keymap ,tabulated-list-sort-button-map))
+ 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))
+ (not-last-col (< n (1- len)))
(label (nth 0 col))
+ (pname label)
(width (nth 1 col))
(props (nthcdr 3 col))
(pad-right (or (plist-get props :pad-right) 1))
@@ -287,24 +290,27 @@ tabulated-list-init-header
(cond
;; An unsortable column
((not (nth 2 col))
- (propertize label 'tabulated-list-column-name label))
+ (propertize label 'tabulated-list-column-name pname))
;; The selected sort column
((equal (car col) (car tabulated-list-sort-key))
- (apply 'propertize
- (concat label
- (cond
- ((> (+ 2 (length label)) width) "")
- ((cdr tabulated-list-sort-key)
- (format " %c"
- tabulated-list-gui-sort-indicator-desc))
- (t (format " %c"
- tabulated-list-gui-sort-indicator-asc))))
- 'face 'bold
- 'tabulated-list-column-name label
- button-props))
+ (let* ((l (length label)))
+ (when (and (>= l 3) (> (+ 2 l) width) not-last-col)
+ (setq label (truncate-string-to-width label (- l 2) nil nil t)))
+ (apply 'propertize
+ (concat label
+ (cond
+ ((and (< l 3) not-last-col) "")
+ ((cdr tabulated-list-sort-key)
+ (format " %c"
+ tabulated-list-gui-sort-indicator-desc))
+ (t (format " %c"
+ tabulated-list-gui-sort-indicator-asc))))
+ 'face 'bold
+ 'tabulated-list-column-name pname
+ button-props)))
;; Unselected sortable column.
(t (apply 'propertize label
- 'tabulated-list-column-name label
+ 'tabulated-list-column-name pname
button-props)))
cols)
(when right-align
^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-20 16:09 ` Stephen Berman
@ 2020-10-29 16:58 ` Stefan Kangas
2020-10-29 22:48 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Stefan Kangas @ 2020-10-29 16:58 UTC (permalink / raw)
To: Stephen Berman, Eli Zaretskii; +Cc: 44068
Stephen Berman <stephen.berman@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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-29 16:58 ` Stefan Kangas
@ 2020-10-29 22:48 ` Stephen Berman
2020-10-30 1:06 ` Stefan Kangas
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-10-29 22:48 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On Thu, 29 Oct 2020 16:58:52 +0000 Stefan Kangas <stefankangas@gmail.com> wrote:
> Stephen Berman <stephen.berman@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?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tabulated-list-init-header patch --]
[-- Type: text/x-patch, Size: 2774 bytes --]
diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
index b13f609f88..4341ad4f92 100644
--- a/lisp/emacs-lisp/tabulated-list.el
+++ b/lisp/emacs-lisp/tabulated-list.el
@@ -269,42 +269,50 @@ tabulated-list-init-header
;; FIXME: Should share code with tabulated-list-print-col!
(let ((x (max tabulated-list-padding 0))
(button-props `(help-echo "Click to sort by column"
- mouse-face header-line-highlight
- keymap ,tabulated-list-sort-button-map))
+ 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))
+ (not-last-col (< n (1- len)))
(label (nth 0 col))
+ (lablen (length label))
+ (pname label)
(width (nth 1 col))
(props (nthcdr 3 col))
(pad-right (or (plist-get props :pad-right) 1))
(right-align (plist-get props :right-align))
(next-x (+ x pad-right width)))
+ (when (and (>= lablen 3)
+ (> (+ 2 lablen) width) not-last-col)
+ (setq label (truncate-string-to-width label (- lablen 2)
+ nil nil t)))
(push
(cond
;; An unsortable column
((not (nth 2 col))
- (propertize label 'tabulated-list-column-name label))
+ (propertize label 'tabulated-list-column-name pname))
;; The selected sort column
((equal (car col) (car tabulated-list-sort-key))
(apply 'propertize
- (concat label
- (cond
- ((> (+ 2 (length label)) width) "")
- ((cdr tabulated-list-sort-key)
+ (concat label
+ (cond
+ ((and (< lablen 3) not-last-col) "")
+ ((cdr tabulated-list-sort-key)
(format " %c"
tabulated-list-gui-sort-indicator-desc))
- (t (format " %c"
+ (t (format " %c"
tabulated-list-gui-sort-indicator-asc))))
- 'face 'bold
- 'tabulated-list-column-name label
- button-props))
+ 'face 'bold
+ 'tabulated-list-column-name pname
+ button-props))
;; Unselected sortable column.
(t (apply 'propertize label
- 'tabulated-list-column-name label
+ 'tabulated-list-column-name pname
button-props)))
cols)
(when right-align
[-- Attachment #3: Type: text/plain, Size: 963 bytes --]
>> 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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-29 22:48 ` Stephen Berman
@ 2020-10-30 1:06 ` Stefan Kangas
2020-10-30 21:44 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Stefan Kangas @ 2020-10-30 1:06 UTC (permalink / raw)
To: Stephen Berman; +Cc: 44068
Stephen Berman <stephen.berman@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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-30 1:06 ` Stefan Kangas
@ 2020-10-30 21:44 ` Stephen Berman
2020-10-30 23:51 ` Stefan Kangas
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-10-30 21:44 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Stephen Berman, 44068
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
On Thu, 29 Oct 2020 18:06:16 -0700 Stefan Kangas <stefankangas@gmail.com> wrote:
> Stephen Berman <stephen.berman@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):
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tabulated-list-init-header patch --]
[-- Type: text/x-patch, Size: 2699 bytes --]
diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
index b13f609f88..30577679f2 100644
--- a/lisp/emacs-lisp/tabulated-list.el
+++ b/lisp/emacs-lisp/tabulated-list.el
@@ -269,42 +269,48 @@ tabulated-list-init-header
;; FIXME: Should share code with tabulated-list-print-col!
(let ((x (max tabulated-list-padding 0))
(button-props `(help-echo "Click to sort by column"
- mouse-face header-line-highlight
- keymap ,tabulated-list-sort-button-map))
+ 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))
+ (not-last-col (< n (1- len)))
(label (nth 0 col))
+ (lablen (length label))
+ (pname label)
(width (nth 1 col))
(props (nthcdr 3 col))
(pad-right (or (plist-get props :pad-right) 1))
(right-align (plist-get props :right-align))
(next-x (+ x pad-right width)))
+ (when (and (>= lablen 3) (> lablen width) not-last-col)
+ (setq label (truncate-string-to-width label (- lablen 1) nil nil t)))
(push
(cond
;; An unsortable column
((not (nth 2 col))
- (propertize label 'tabulated-list-column-name label))
+ (propertize label 'tabulated-list-column-name pname))
;; The selected sort column
((equal (car col) (car tabulated-list-sort-key))
(apply 'propertize
- (concat label
- (cond
- ((> (+ 2 (length label)) width) "")
- ((cdr tabulated-list-sort-key)
+ (concat label
+ (cond
+ ((and (< lablen 3) not-last-col) "")
+ ((cdr tabulated-list-sort-key)
(format " %c"
tabulated-list-gui-sort-indicator-desc))
- (t (format " %c"
+ (t (format " %c"
tabulated-list-gui-sort-indicator-asc))))
- 'face 'bold
- 'tabulated-list-column-name label
- button-props))
+ 'face 'bold
+ 'tabulated-list-column-name pname
+ button-props))
;; Unselected sortable column.
(t (apply 'propertize label
- 'tabulated-list-column-name label
+ 'tabulated-list-column-name pname
button-props)))
cols)
(when right-align
[-- Attachment #3: Type: text/plain, Size: 986 bytes --]
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
^ permalink raw reply related [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-30 21:44 ` Stephen Berman
@ 2020-10-30 23:51 ` Stefan Kangas
2020-11-01 23:07 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Stefan Kangas @ 2020-10-30 23:51 UTC (permalink / raw)
To: Stephen Berman; +Cc: 44068
Stephen Berman <stephen.berman@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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-10-30 23:51 ` Stefan Kangas
@ 2020-11-01 23:07 ` Stephen Berman
2020-11-02 17:12 ` Eli Zaretskii
2020-11-04 12:02 ` Stefan Kangas
0 siblings, 2 replies; 31+ messages in thread
From: Stephen Berman @ 2020-11-01 23:07 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068
On Fri, 30 Oct 2020 23:51:21 +0000 Stefan Kangas <stefankangas@gmail.com> wrote:
> Stephen Berman <stephen.berman@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-01 23:07 ` Stephen Berman
@ 2020-11-02 17:12 ` Eli Zaretskii
2020-11-02 22:37 ` Stephen Berman
2020-11-04 12:02 ` Stefan Kangas
1 sibling, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2020-11-02 17:12 UTC (permalink / raw)
To: Stephen Berman; +Cc: stefankangas, 44068
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 44068@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.)
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-02 17:12 ` Eli Zaretskii
@ 2020-11-02 22:37 ` Stephen Berman
2020-11-03 3:27 ` Eli Zaretskii
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-11-02 22:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, 44068
On Mon, 02 Nov 2020 19:12:16 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 44068@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@gnu.org>, I wanted to make sure you also accept the
result.
Steve Berman
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-02 22:37 ` Stephen Berman
@ 2020-11-03 3:27 ` Eli Zaretskii
2020-11-03 23:12 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2020-11-03 3:27 UTC (permalink / raw)
To: Stephen Berman; +Cc: stefankangas, 44068
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: stefankangas@gmail.com, 44068@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@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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-03 3:27 ` Eli Zaretskii
@ 2020-11-03 23:12 ` Stephen Berman
2020-11-04 15:09 ` Eli Zaretskii
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-11-03 23:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, 44068
On Tue, 03 Nov 2020 05:27:30 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: stefankangas@gmail.com, 44068@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@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-01 23:07 ` Stephen Berman
2020-11-02 17:12 ` Eli Zaretskii
@ 2020-11-04 12:02 ` Stefan Kangas
2020-11-04 22:53 ` Stephen Berman
1 sibling, 1 reply; 31+ messages in thread
From: Stefan Kangas @ 2020-11-04 12:02 UTC (permalink / raw)
To: Stephen Berman; +Cc: 44068
Stephen Berman <stephen.berman@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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-03 23:12 ` Stephen Berman
@ 2020-11-04 15:09 ` Eli Zaretskii
2020-11-04 22:55 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Eli Zaretskii @ 2020-11-04 15:09 UTC (permalink / raw)
To: Stephen Berman; +Cc: stefankangas, 44068
> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: stefankangas@gmail.com, 44068@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.
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-04 12:02 ` Stefan Kangas
@ 2020-11-04 22:53 ` Stephen Berman
2020-11-12 16:38 ` Stefan Kangas
0 siblings, 1 reply; 31+ messages in thread
From: Stephen Berman @ 2020-11-04 22:53 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068
On Wed, 4 Nov 2020 04:02:04 -0800 Stefan Kangas <stefankangas@gmail.com> wrote:
> Stephen Berman <stephen.berman@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-04 15:09 ` Eli Zaretskii
@ 2020-11-04 22:55 ` Stephen Berman
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Berman @ 2020-11-04 22:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: stefankangas, 44068
On Wed, 04 Nov 2020 17:09:30 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: stefankangas@gmail.com, 44068@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
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-04 22:53 ` Stephen Berman
@ 2020-11-12 16:38 ` Stefan Kangas
2020-11-12 22:51 ` Stephen Berman
0 siblings, 1 reply; 31+ messages in thread
From: Stefan Kangas @ 2020-11-12 16:38 UTC (permalink / raw)
To: Stephen Berman; +Cc: 44068
Stephen Berman <stephen.berman@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?
^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#44068: 28.0.50; Faulty uses of tabulated-list-format
2020-11-12 16:38 ` Stefan Kangas
@ 2020-11-12 22:51 ` Stephen Berman
0 siblings, 0 replies; 31+ messages in thread
From: Stephen Berman @ 2020-11-12 22:51 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 44068-done
On Thu, 12 Nov 2020 11:38:04 -0500 Stefan Kangas <stefankangas@gmail.com> wrote:
> Stephen Berman <stephen.berman@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
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2020-11-12 22:51 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-18 20:00 bug#44068: 28.0.50; Faulty uses of tabulated-list-format Stephen Berman
2020-10-18 21:33 ` Drew Adams
2020-10-18 22:01 ` Stefan Kangas
2020-10-18 22:15 ` Drew Adams
2020-10-18 22:18 ` Stephen Berman
2020-10-18 22:01 ` Stefan Kangas
2020-10-18 22:17 ` Stephen Berman
2020-10-18 22:35 ` Stephen Berman
2020-10-18 23:13 ` Stefan Kangas
2020-10-19 9:04 ` Stephen Berman
2020-10-19 13:52 ` Eli Zaretskii
2020-10-19 18:20 ` Stephen Berman
2020-10-19 18:43 ` Eli Zaretskii
2020-10-19 19:12 ` Stephen Berman
2020-10-20 16:09 ` Stephen Berman
2020-10-29 16:58 ` Stefan Kangas
2020-10-29 22:48 ` Stephen Berman
2020-10-30 1:06 ` Stefan Kangas
2020-10-30 21:44 ` Stephen Berman
2020-10-30 23:51 ` Stefan Kangas
2020-11-01 23:07 ` Stephen Berman
2020-11-02 17:12 ` Eli Zaretskii
2020-11-02 22:37 ` Stephen Berman
2020-11-03 3:27 ` Eli Zaretskii
2020-11-03 23:12 ` Stephen Berman
2020-11-04 15:09 ` Eli Zaretskii
2020-11-04 22:55 ` Stephen Berman
2020-11-04 12:02 ` Stefan Kangas
2020-11-04 22:53 ` Stephen Berman
2020-11-12 16:38 ` Stefan Kangas
2020-11-12 22:51 ` Stephen Berman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).