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

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44068 <at> debbugs.gnu.org
Subject: 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)]

Previous Next

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