bug#44068: 28.0.50; Faulty uses of tabulated-list-format

[Stephen Berman]

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

txtdrTIQYDxIZ.txt
Description: tabulated-list-init-header patch

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