GNU bug report logs - #21932
24.3.1; tabulated-list-mode minor bugs and feature requests

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> raeburn.org>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 24.3.1; tabulated-list-mode minor bugs and feature requests
Date: Mon, 16 Nov 2015 03:14:39 -0500

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

Previous Next

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