From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#44068: 28.0.50; Faulty uses of tabulated-list-format Date: Fri, 30 Oct 2020 22:44:48 +0100 Message-ID: <875z6rmlrj.fsf@rub.de> References: <87imb7e242.fsf@gmx.net> <83zh4ipbli.fsf@gnu.org> <877drm13j3.fsf@gmx.net> <831rhuoy36.fsf@gnu.org> <87y2k2yqqb.fsf@gmx.net> <87h7qori97.fsf@gmx.net> <874kmcfy2h.fsf@rub.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22283"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stephen Berman , 44068@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 30 22:45:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kYcCs-0005it-Rl for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Oct 2020 22:45:10 +0100 Original-Received: from localhost ([::1]:47416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYcCr-0001PX-Tq for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Oct 2020 17:45:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39600) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYcCl-0001PK-2X for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 17:45:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48484) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYcCk-00016H-OG for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 17:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kYcCk-0002Tb-ME for bug-gnu-emacs@gnu.org; Fri, 30 Oct 2020 17:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Oct 2020 21:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44068 X-GNU-PR-Package: emacs Original-Received: via spool by 44068-submit@debbugs.gnu.org id=B44068.16040943029506 (code B ref 44068); Fri, 30 Oct 2020 21:45:02 +0000 Original-Received: (at 44068) by debbugs.gnu.org; 30 Oct 2020 21:45:02 +0000 Original-Received: from localhost ([127.0.0.1]:60030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYcCj-0002T6-Fi for submit@debbugs.gnu.org; Fri, 30 Oct 2020 17:45:01 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:54017) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYcCh-0002Sl-W7 for 44068@debbugs.gnu.org; Fri, 30 Oct 2020 17:45:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604094293; bh=TaqU9qWarLfvrjurZa1qu+uHbIMjVcDZl13/5Nqcq0s=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=AN0O2gNmRuz8KzocjoUN1awnj0xNkHQKR96Rn1KzYWJiiC6+cMjGcBIr9PCgpWYI7 r+UPClnr93jOE7EoVjxuSJJLEV/26T6E2zMKQsZx/f2SkqfjYWh0Aw1xbY/Hr8YeGi 24eJVYDGpIFDuwbbHgNIatxHpt2atSV6Ia+I2jA4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from strobe-jhalfs ([92.73.67.224]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MzyuS-1kC1PH1foU-00x1fQ; Fri, 30 Oct 2020 22:44:53 +0100 In-Reply-To: (Stefan Kangas's message of "Thu, 29 Oct 2020 18:06:16 -0700") X-Provags-ID: V03:K1:mYrWMTM/dX5TGnNhreghaegGB2t53xXvEf6aBUSvroj4GAdDbZB 8TgSMBND2qnBd+0vfz7l/i9g/lMIogv17+YtHykaPmGqIJ7tgkmTckU6k9FscRSiZqoA4DS zF8fu1hWk3vQrW0w3USaoTEaf44yiP8j2IjgMucMa7J8kCenumsBtk4jpE5gZ10B542T9uO Nq6slzNPrWNPM/zD/IBZQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:f/1FsUJL7D4=:55L1/zl80n4A3US+8NmF5m BW2DnrBWgBa/My324nBDKhVmnatBKGr8a2plOwRaWY3kxRhnh+cNkt+FC56YPDeRS52syL2os KO6p3his7+9OVW+u4RHQn4Z6zXb/Kwscm+rNPpthkLBYEvAqyNkoDUlRQkQCWo4y/pzkZhE9r IE2vKcYMXPXQEGJ4Ldl5QNh1hRmbbk8KYD+1CSxwfUKdGlZLMhWdThHcxaQlWkRyPFPS/38+6 ol2VBIgNKLAHnKoHSXRBlR7gJ+FrZQaCmfp5NLJbXKE+zQaaPnn7mSBKDb+VLnBOhgerE5M0E V7N0Nd/gYf0ZUSySXOqERrg7v7ZGAT10msuh1c3G5UzbmXxNFnIopKCJmQbC8X4/1BUuarAQn STl9k6TFERwJGbjh1GukjgnA010J52iJvzEpxeDMtZiWmWxNPz2gej6lXC6/40Ga4YVSPHn9T YCnlGRdJmdMQUwU1d7khPd6qhalrUhwVDUjA5t+AENpcRMmHPOltwKqs3G2FaKdIS19TJtLZ4 RNhGvoz2+Oa6C7JQ1D9jgFNS68j5eWDYNh2vq/Av8P/uPKms9s2KU1s7sp0vV1c57Jdqq/qDg cvma/yJpHCLEI47DQASHDP/uiE/EDf+BFvJ4zvd5qHb4T2DR0DlDx6H/gn/kxpgvn7wcivFbB WR3ipqdxNSm9ZMQhAzUohhXwqXdWujoagp2gyjVuCRs//dhVCLd/qv7UciBirOamA+0M3SHpb MVz+5oM/UNzN9GTnRZijCf55DjBUvAFlFMfED5ySigf7htIjNsl2QIgx/h4soltIyZ5VCwqO X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192211 Archived-At: --=-=-= Content-Type: text/plain On Thu, 29 Oct 2020 18:06:16 -0700 Stefan Kangas wrote: > Stephen Berman 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): --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Description: tabulated-list-init-header patch 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 --=-=-= Content-Type: text/plain 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 --=-=-=--