bug#21932: 24.3.1; tabulated-list-mode minor bugs and feature requests

bug#21932: 24.3.1; tabulated-list-mode minor bugs and feature requests

[Ken Raeburn]

Tabulated list mode is quite a nice helper for viewing information.  I’ve used it to throw together various simple modes for debugging other Emacs code or for work — listing Emacs timers, listing Emacs frames and which displays they’re on, listing my Perforce workspaces with descriptions.

In using it, I have run across a few minor issues, and have a few enhancements I’d like to see.

1) Tabulated list mode doesn’t line the columns up properly if you use C-x C— or C-x C-+ to alter the text size.  The columns are not lined up consistently, though in the mode I’m writing right now, some of them do seem to stay lined up with the headers if I shrink the text.

2) When changing the text size, the text of the header line is unchanged.  If this is intentional, then the number of characters in each column should be adjusted up or down to compensate, so that entry columns aren’t too wide, and aren’t truncated to a much narrower width than necessary.  I would guess it’s accidental, though.

3) Tabulated list mode doesn’t line the columns up properly if you use variable-pitch-mode.  This one is hard, I’m sure, because the same buffer could simultaneously be displayed on multiple displays that support different fonts, and on terminals that don’t support anything but one fixed-width font.  If we don’t truncate each string to the shortest length useable across all frames displaying the buffer based on font metrics and the specific text to be displayed, which would probably look kind of ugly (…but might not?), then I think we need the display engine to make the choice where to truncate rather than the Lisp code.

4) On most graphical displays it should be capable of using the Unicode ellipsis code point U+2026 instead of taking up three columns with dots; that would give us back two columns of text on such displays.  Again, this would be potentially displaying different amounts of text, as well as different ellipses, on different displays.

5) Adjustable column widths: Many table-based GUIs I’ve seen let the user grab the dividing line between headers and drag it left or right to alter a field’s width, sometimes with limits to how wide or narrow the field is allowed to be.  It wouldn’t work for every case, but when there is a padding space between column headers, perhaps it can be given mouse bindings similar to the way mouse-drag-vertical-line works.

Ken

bug#21932: 24.3.1; tabulated-list-mode minor bugs and feature requests

[Stefan Kangas]

Ken Raeburn <raeburn@raeburn.org> writes:

> 1) Tabulated list mode doesn’t line the columns up properly if you use C-x C— or
> C-x C-+ to alter the text size.

This is still an issue.

> 2) When changing the text size, the text of the header line is unchanged.

See the patch in Bug#41852.  Perhaps the work regarding this can
continue there.

> 3) Tabulated list mode doesn’t line the columns up properly if you use
> variable-pitch-mode.

This is still an issue.

> 4) On most graphical displays it should be capable of using the Unicode ellipsis
> code point U+2026 instead of taking up three columns with dots;

This seems to have been fixed since this bug was reported.

> 5) Adjustable column widths: Many table-based GUIs I’ve seen let the user grab
> the dividing line between headers and drag it left or right to alter a field’s
> width, sometimes with limits to how wide or narrow the field is allowed to be.
> It wouldn’t work for every case, but when there is a padding space between
> column headers, perhaps it can be given mouse bindings similar to the way
> mouse-drag-vertical-line works.

We now have the commands `{' (`tabulated-list-narrow-current-column')
and `}' (`tabulated-list-widen-current-column').  But it would be nice
to also have controls to change the widths using the mouse.  I guess the
challenge would be to ensure that it worked smoothly, as the mentioned
commands are fairly slow (average 0.4 seconds on my machine in
`list-packages').