unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stephen Berman <stephen.berman@gmx.net>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: Stephen Berman <stephen.berman@gmx.net>, 44068@debbugs.gnu.org
Subject: bug#44068: 28.0.50; Faulty uses of tabulated-list-format
Date: Fri, 30 Oct 2020 22:44:48 +0100	[thread overview]
Message-ID: <875z6rmlrj.fsf@rub.de> (raw)
In-Reply-To: <CADwFkm=upbQ5LFXHcJ_n6CXFH4zu_nv63tVWiAd-SXX7V-ZaJA@mail.gmail.com> (Stefan Kangas's message of "Thu, 29 Oct 2020 18:06:16 -0700")

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tabulated-list-init-header patch --]
[-- Type: text/x-patch, Size: 2699 bytes --]

diff --git a/lisp/emacs-lisp/tabulated-list.el b/lisp/emacs-lisp/tabulated-list.el
index b13f609f88..30577679f2 100644
--- a/lisp/emacs-lisp/tabulated-list.el
+++ b/lisp/emacs-lisp/tabulated-list.el
@@ -269,42 +269,48 @@ tabulated-list-init-header
   ;; FIXME: Should share code with tabulated-list-print-col!
   (let ((x (max tabulated-list-padding 0))
 	(button-props `(help-echo "Click to sort by column"
-			mouse-face header-line-highlight
-			keymap ,tabulated-list-sort-button-map))
+			          mouse-face header-line-highlight
+			          keymap ,tabulated-list-sort-button-map))
+        (len (length tabulated-list-format))
 	(cols nil))
     (if display-line-numbers
         (setq x (+ x (tabulated-list-line-number-width))))
     (push (propertize " " 'display `(space :align-to ,x)) cols)
-    (dotimes (n (length tabulated-list-format))
+    (dotimes (n len)
       (let* ((col (aref tabulated-list-format n))
+             (not-last-col (< n (1- len)))
 	     (label (nth 0 col))
+             (lablen (length label))
+             (pname label)
 	     (width (nth 1 col))
 	     (props (nthcdr 3 col))
 	     (pad-right (or (plist-get props :pad-right) 1))
              (right-align (plist-get props :right-align))
              (next-x (+ x pad-right width)))
+        (when (and (>= lablen 3) (> lablen width) not-last-col)
+          (setq label (truncate-string-to-width label (- lablen 1) nil nil t)))
 	(push
 	 (cond
 	  ;; An unsortable column
 	  ((not (nth 2 col))
-	   (propertize label 'tabulated-list-column-name label))
+	   (propertize label 'tabulated-list-column-name pname))
 	  ;; The selected sort column
 	  ((equal (car col) (car tabulated-list-sort-key))
 	   (apply 'propertize
-		  (concat label
-			  (cond
-			   ((> (+ 2 (length label)) width) "")
-			   ((cdr tabulated-list-sort-key)
+                  (concat label
+                          (cond
+                           ((and (< lablen 3) not-last-col) "")
+                           ((cdr tabulated-list-sort-key)
                             (format " %c"
                                     tabulated-list-gui-sort-indicator-desc))
-			   (t (format " %c"
+                           (t (format " %c"
                                       tabulated-list-gui-sort-indicator-asc))))
-		  'face 'bold
-		  'tabulated-list-column-name label
-		  button-props))
+                  'face 'bold
+                  'tabulated-list-column-name pname
+                  button-props))
 	  ;; Unselected sortable column.
 	  (t (apply 'propertize label
-		    'tabulated-list-column-name label
+		    'tabulated-list-column-name pname
 		    button-props)))
 	 cols)
         (when right-align

[-- Attachment #3: Type: text/plain, Size: 986 bytes --]


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

  reply	other threads:[~2020-10-30 21:44 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-18 20:00 bug#44068: 28.0.50; Faulty uses of tabulated-list-format Stephen Berman
2020-10-18 21:33 ` Drew Adams
2020-10-18 22:01   ` Stefan Kangas
2020-10-18 22:15     ` Drew Adams
2020-10-18 22:18     ` Stephen Berman
2020-10-18 22:01 ` Stefan Kangas
2020-10-18 22:17   ` Stephen Berman
2020-10-18 22:35     ` Stephen Berman
2020-10-18 23:13       ` Stefan Kangas
2020-10-19  9:04         ` Stephen Berman
2020-10-19 13:52 ` Eli Zaretskii
2020-10-19 18:20   ` Stephen Berman
2020-10-19 18:43     ` Eli Zaretskii
2020-10-19 19:12       ` Stephen Berman
2020-10-20 16:09         ` Stephen Berman
2020-10-29 16:58           ` Stefan Kangas
2020-10-29 22:48             ` Stephen Berman
2020-10-30  1:06               ` Stefan Kangas
2020-10-30 21:44                 ` Stephen Berman [this message]
2020-10-30 23:51                   ` Stefan Kangas
2020-11-01 23:07                     ` Stephen Berman
2020-11-02 17:12                       ` Eli Zaretskii
2020-11-02 22:37                         ` Stephen Berman
2020-11-03  3:27                           ` Eli Zaretskii
2020-11-03 23:12                             ` Stephen Berman
2020-11-04 15:09                               ` Eli Zaretskii
2020-11-04 22:55                                 ` Stephen Berman
2020-11-04 12:02                       ` Stefan Kangas
2020-11-04 22:53                         ` Stephen Berman
2020-11-12 16:38                           ` Stefan Kangas
2020-11-12 22:51                             ` Stephen Berman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875z6rmlrj.fsf@rub.de \
    --to=stephen.berman@gmx.net \
    --cc=44068@debbugs.gnu.org \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).