bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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


Hello,

The pretty print in the find buffer doesn't line up the columns, see

 => https://sdf.org/~van.ly/img/emacs-30-0-91-pretest-find-buffer.jpeg

To reproduce on 1080p display, do

 1. emacs -Q
 2. apply, M-x find-name-dired RET
 3. target at a srcdir like NetBSD-10 and toggle fullscreen

Expect to see columns line up in pretty print.


[-- Attachment #2: bug-gnu-emacs-report.text --]
[-- Type: application/octet-stream, Size: 4509 bytes --]

From: xxx@xxx.mail-host-address-is-not-set
To: bug-gnu-emacs@gnu.org
Subject: 30.0.91; x
X-Debbugs-Cc: 
--text follows this line--




In GNU Emacs 30.0.91 (build 2, x86_64--netbsd, X toolkit, cairo version
 1.18.0) of 2024-09-15 built on xxx
Windowing system distributor 'The X.Org Foundation', version 11.0.12101009
System Description: NetBSD xxx 10.0_STABLE NetBSD 10.0_STABLE (GENERIC) #0: Thu Aug  8 07:34:54 UTC 2024  mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64

Configured using:
 'configure --srcdir=/u/xxx/src/emacs/30.0.91 --localstatedir=/var
 --disable-autodepend --with-native-compilation --without-ns
 --without-rsvg --without-imagemagick --without-xaw3d
 --without-toolkit-scroll-bars --x-includes=/usr/X11R7/include
 --x-libraries=/usr/X11R7/lib --with-x-toolkit=lu --prefix=/usr/local
 --build=x86_64--netbsd --host=x86_64--netbsd --infodir=/usr/pkg/info
 --mandir=/usr/pkg/man --enable-option-checking=yes 'CFLAGS=-O2
 -I/usr/pkg/include/cairo -I/usr/pkg/include -I/usr/include
 -I/usr/pkg/include/freetype2 -I/usr/pkg/include/glib-2.0
 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include
 -I/usr/X11R7/include -I/usr/pkg/include/harfbuzz
 -I/usr/X11R7/include/libdrm' 'CPPFLAGS=-DTERMINFO -I/usr/pkg/include
 -I/usr/include -I/usr/pkg/include/freetype2 -I/usr/pkg/include/glib-2.0
 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include
 -I/usr/X11R7/include -I/usr/pkg/include/harfbuzz
 -I/usr/X11R7/include/libdrm' 'LDFLAGS=-Wl,-R/usr/pkg/gcc13/lib
 -Wl,-zrelro -L/usr/pkg/lib -lcairo -L/usr/lib -Wl,-R/usr/lib
 -Wl,-R/usr/pkg/lib -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LCMS2 LIBOTF LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE PDUMPER PNG SOUND
SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM LUCID
ZLIB

Important settings:
  value of $LC_COLLATE: en_AU.UTF-8
  value of $LC_CTYPE: en_AU.UTF-8
  value of $LC_MESSAGES: en_AU.UTF-8
  value of $LC_MONETARY: en_AU.UTF-8
  value of $LC_NUMERIC: en_AU.UTF-8
  value of $LC_TIME: en_AU.UTF-8
  value of $LANG: en_AU.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow mail-extr emacsbug message mailcap yank-media puny rfc822 mml
mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils sort files-x find-dired
dired dired-loaddefs face-remap help-mode cl-loaddefs cl-lib help-macro
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind kqueue lcms2 dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)

Memory information:
((conses 16 68353 9035) (symbols 48 5560 0) (strings 32 15417 1819)
 (string-bytes 1 457168) (vectors 16 9419)
 (vector-slots 8 130868 10152) (floats 8 29 1) (intervals 56 2911 284)
 (buffers 992 12))

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



-- 
vl

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Eli Zaretskii]

> Date: Tue, 24 Sep 2024 15:27:55 +0000
> From:  Van Ly via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> The pretty print in the find buffer doesn't line up the columns, see
> 
>  => https://sdf.org/~van.ly/img/emacs-30-0-91-pretest-find-buffer.jpeg
> 
> To reproduce on 1080p display, do
> 
>  1. emacs -Q
>  2. apply, M-x find-name-dired RET
>  3. target at a srcdir like NetBSD-10 and toggle fullscreen
> 
> Expect to see columns line up in pretty print.

If you run the 'find' command shown at the beginning of the buffer
from the shell prompt, after you chdir to the NetBSD-10 directory, do
the columns align in the output, or do you see the same misalignment
as in the screenshot you posted?

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> 
>> Expect to see columns line up in pretty print.
>
> If you run the 'find' command shown at the beginning of the buffer
> from the shell prompt, after you chdir to the NetBSD-10 directory, do
> the columns align in the output, or do you see the same misalignment
> as in the screenshot you posted?
>

That command at the shell prompt inside Emacs and outside on the Xterm

 $ find . \( -name \*file.c \) -ls

generates misaligned columns as seen in the screenshot.  Here is a
clip of three lines taken from the Xterm and this is also misaligned inside
Emacs at the shell prompt output

 799508     16 -rw-r--r--    1 van               wheel                  6006 May 22  2021 ./sys/lib/libsa/loadfile.c
12794193     16 -rw-r--r--    1 van               wheel                  4161 Jul 15  2020 ./sys/stand/efiboot/efifile.c
 807438      8 -rw-r--r--    1 van               wheel                  3571 Jan 14  2017 ./tests/kernel/kqueue/read/t_file.c


-- 
vl

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Eli Zaretskii]

> From: Van Ly <van.ly@sdf.org>
> Cc: 73455@debbugs.gnu.org
> Date: Wed, 25 Sep 2024 09:39:38 +0000
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 
> >> Expect to see columns line up in pretty print.
> >
> > If you run the 'find' command shown at the beginning of the buffer
> > from the shell prompt, after you chdir to the NetBSD-10 directory, do
> > the columns align in the output, or do you see the same misalignment
> > as in the screenshot you posted?
> >
> 
> That command at the shell prompt inside Emacs and outside on the Xterm
> 
>  $ find . \( -name \*file.c \) -ls
> 
> generates misaligned columns as seen in the screenshot.  Here is a
> clip of three lines taken from the Xterm and this is also misaligned inside
> Emacs at the shell prompt output
> 
>  799508     16 -rw-r--r--    1 van               wheel                  6006 May 22  2021 ./sys/lib/libsa/loadfile.c
> 12794193     16 -rw-r--r--    1 van               wheel                  4161 Jul 15  2020 ./sys/stand/efiboot/efifile.c
>  807438      8 -rw-r--r--    1 van               wheel                  3571 Jan 14  2017 ./tests/kernel/kqueue/read/t_file.c

Then I think this is the reason.  Emacs does not realign the columns
in the output of the Find command, it uses the output as-is.  Since
you are on NetBSD, I'm guessing that your Find command is not GNU
Find, and it probably doesn't guarantee that the columns are aligned.
I think I see in the GNU Find code which tries to handle this case, so
maybe you could install GNU Find and try with that.

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>
>                                   Emacs does not realign the columns
> in the output of the Find command, it uses the output as-is.  Since
> you are on NetBSD, I'm guessing that your Find command is not GNU
> Find, and it probably doesn't guarantee that the columns are aligned.
> I think I see in the GNU Find code which tries to handle this case, so
> maybe you could install GNU Find and try with that.
>

The GNU findutils package offers pkg/gnu/bin/find and pkg/bin/gfind as
follows, and the column alignment is correct in the GNU find.  Emacs
doesn't seem to have a configuration option to override the system's
find with gfind from GNU.

Placing in PATH /usr/pkg/gnu/bin:/usr/pkg/bin:/usr/bin has the potential
to knock-on unwanted side-effects where tools prefer the base system
commands. An example would be make and gmake.

 1 $ pkgin pkg-content findutils
 2 Information for https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/x86_64/10.0_2024Q2/All/findutils-4.9.0.tgz:
 3 Files:
 4 /usr/pkg/bin/gfind
 5 /usr/pkg/bin/glocate
 6 /usr/pkg/bin/gupdatedb
 7 /usr/pkg/bin/gxargs
 8 /usr/pkg/gnu/bin/find
 9 /usr/pkg/gnu/bin/locate
10 /usr/pkg/gnu/bin/updatedb
11 /usr/pkg/gnu/bin/xargs

-- 
vl

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Eli Zaretskii]

> From: Van Ly <van.ly@sdf.org>
> Cc: 73455@debbugs.gnu.org
> Date: Wed, 25 Sep 2024 15:36:58 +0000
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >
> >                                   Emacs does not realign the columns
> > in the output of the Find command, it uses the output as-is.  Since
> > you are on NetBSD, I'm guessing that your Find command is not GNU
> > Find, and it probably doesn't guarantee that the columns are aligned.
> > I think I see in the GNU Find code which tries to handle this case, so
> > maybe you could install GNU Find and try with that.
> >
> 
> The GNU findutils package offers pkg/gnu/bin/find and pkg/bin/gfind as
> follows, and the column alignment is correct in the GNU find.  Emacs
> doesn't seem to have a configuration option to override the system's
> find with gfind from GNU.

You should be able to accomplish that by setting the value of the
variable find-program to "gfind".

> Placing in PATH /usr/pkg/gnu/bin:/usr/pkg/bin:/usr/bin has the potential
> to knock-on unwanted side-effects where tools prefer the base system
> commands. An example would be make and gmake.

If you set the value of find-program to "gfind", I think you should be
able to add only /usr/pkg/bin to PATH, and that should not override
the original "find", "make", etc.

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> If you set the value of find-program to "gfind", I think you should be
> able to add only /usr/pkg/bin to PATH, and that should not override
> the original "find", "make", etc.

Would it be worth considering doing the same as we did for
`insert-directory-program`, i.e. the below?  I'm not sure if this would
be considered too opinionated for people that are very used to a BSD
userland.

This still requires GNU find to be installed, of course (on macOS with
Homebrew, that would be `brew install findutils`).

diff --git a/lisp/progmodes/grep.el b/lisp/progmodes/grep.el
index b453ac60ed2..97583c8afb8 100644
--- a/lisp/progmodes/grep.el
+++ b/lisp/progmodes/grep.el
@@ -550,7 +550,11 @@ grep-program
 This variable's value takes effect when `grep-compute-defaults' is called.")

 ;;;###autoload
-(defvar find-program (purecopy "find")
+(defvar find-program
+  (if (and (memq system-type '(berkeley-unix darwin))
+           (executable-find "gfind"))
+      (purecopy "gfind")
+    (purecopy "find"))
   "The default find program.
 This is used by commands like `grep-find-command', `find-dired'
 and others.")

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Wed, 25 Sep 2024 10:24:32 -0700
> Cc: 73455@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If you set the value of find-program to "gfind", I think you should be
> > able to add only /usr/pkg/bin to PATH, and that should not override
> > the original "find", "make", etc.
> 
> Would it be worth considering doing the same as we did for
> `insert-directory-program`, i.e. the below?  I'm not sure if this would
> be considered too opinionated for people that are very used to a BSD
> userland.

I'm not sure.  find-program is used in many places, most of them
unrelated to alignment in "find ... -ls", so we are basically skewing
everything for a single not very frequent case.  Why not leave that to
users instead?

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Van Ly via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Wed, 25 Sep 2024 10:24:32 -0700
>> Cc: 73455@debbugs.gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > If you set the value of find-program to "gfind", I think you should be
>> > able to add only /usr/pkg/bin to PATH, and that should not override
>> > the original "find", "make", etc.
>> 
>> Would it be worth considering doing the same as we did for
>> `insert-directory-program`, i.e. the below?  I'm not sure if this would
>> be considered too opinionated for people that are very used to a BSD
>> userland.
>
> I'm not sure.  find-program is used in many places, most of them
> unrelated to alignment in "find ... -ls", so we are basically skewing
> everything for a single not very frequent case.  Why not leave that to
> users instead?
>

Perhaps BSD userland package maintainers will roll in and configure the
GNU Findutils option.  Maybe FAQ documentation to help the maintainer or
BSD user is enough.  Dired mode hints when the ls command doesn't handle
the dired switch option.  If the apropos-command could have a way to
find the find-program variable that will help the end-user.  The
describe-variable command will auto-complete "find" or "program" to
"find-program", could describe-variable dump a listing like
apropos-command?

Thanks.

-- 
vl

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Eli Zaretskii]

> From: Van Ly <van.ly@sdf.org>
> Cc: stefankangas@gmail.com, 73455@debbugs.gnu.org
> Date: Thu, 26 Sep 2024 13:20:31 +0000
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Stefan Kangas <stefankangas@gmail.com>
> >> Date: Wed, 25 Sep 2024 10:24:32 -0700
> >> Cc: 73455@debbugs.gnu.org
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > If you set the value of find-program to "gfind", I think you should be
> >> > able to add only /usr/pkg/bin to PATH, and that should not override
> >> > the original "find", "make", etc.
> >> 
> >> Would it be worth considering doing the same as we did for
> >> `insert-directory-program`, i.e. the below?  I'm not sure if this would
> >> be considered too opinionated for people that are very used to a BSD
> >> userland.
> >
> > I'm not sure.  find-program is used in many places, most of them
> > unrelated to alignment in "find ... -ls", so we are basically skewing
> > everything for a single not very frequent case.  Why not leave that to
> > users instead?
> >
> 
> Perhaps BSD userland package maintainers will roll in and configure the
> GNU Findutils option.  Maybe FAQ documentation to help the maintainer or
> BSD user is enough.  Dired mode hints when the ls command doesn't handle
> the dired switch option.  If the apropos-command could have a way to
> find the find-program variable that will help the end-user.  The
> describe-variable command will auto-complete "find" or "program" to
> "find-program", could describe-variable dump a listing like
> apropos-command?

I already added to the doc string of find-dired a recommendation to
install GNU Find and the reference to `find-program'.

bug#73455: 30.0.91: find buffer pretty print columns don't line up on 1080p

[Eli Zaretskii]

> Cc: stefankangas@gmail.com, 73455@debbugs.gnu.org
> Date: Thu, 26 Sep 2024 17:11:18 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Van Ly <van.ly@sdf.org>
> > Cc: stefankangas@gmail.com, 73455@debbugs.gnu.org
> > Date: Thu, 26 Sep 2024 13:20:31 +0000
> > 
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> From: Stefan Kangas <stefankangas@gmail.com>
> > >> Date: Wed, 25 Sep 2024 10:24:32 -0700
> > >> Cc: 73455@debbugs.gnu.org
> > >> 
> > >> Eli Zaretskii <eliz@gnu.org> writes:
> > >> 
> > >> > If you set the value of find-program to "gfind", I think you should be
> > >> > able to add only /usr/pkg/bin to PATH, and that should not override
> > >> > the original "find", "make", etc.
> > >> 
> > >> Would it be worth considering doing the same as we did for
> > >> `insert-directory-program`, i.e. the below?  I'm not sure if this would
> > >> be considered too opinionated for people that are very used to a BSD
> > >> userland.
> > >
> > > I'm not sure.  find-program is used in many places, most of them
> > > unrelated to alignment in "find ... -ls", so we are basically skewing
> > > everything for a single not very frequent case.  Why not leave that to
> > > users instead?
> > >
> > 
> > Perhaps BSD userland package maintainers will roll in and configure the
> > GNU Findutils option.  Maybe FAQ documentation to help the maintainer or
> > BSD user is enough.  Dired mode hints when the ls command doesn't handle
> > the dired switch option.  If the apropos-command could have a way to
> > find the find-program variable that will help the end-user.  The
> > describe-variable command will auto-complete "find" or "program" to
> > "find-program", could describe-variable dump a listing like
> > apropos-command?
> 
> I already added to the doc string of find-dired a recommendation to
> install GNU Find and the reference to `find-program'.

No further comments, so I'm now closing this bug.