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: 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: 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.

Previous Next

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