[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44068: 28.0.50; Faulty uses of tabulated-list-format
From: |
Stephen Berman |
Subject: |
bug#44068: 28.0.50; Faulty uses of tabulated-list-format |
Date: |
Tue, 20 Oct 2020 18:09:56 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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
txtS9k5keGa0k.txt
Description: tabulated-list-init-header patch
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, (continued)
bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Eli Zaretskii, 2020/10/19
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Stephen Berman, 2020/10/19
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Eli Zaretskii, 2020/10/19
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Stephen Berman, 2020/10/19
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format,
Stephen Berman <=
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Stefan Kangas, 2020/10/29
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Stephen Berman, 2020/10/29
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Stefan Kangas, 2020/10/29
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Stephen Berman, 2020/10/30
- bug#44068: 28.0.50; Faulty uses of tabulated-list-format, Stefan Kangas, 2020/10/30