bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Jean Louis]

I have files like:

~/tmp/2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt

and if I do M-x grep on those files, I get results such as:

2024-01-22-11:39:12-RCD TEMPORARY BUFFER.txt:13:|            | TOTAL                                      |  -57000 |
2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:3:|------------+-------------------------------+---------|
2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:4:|       Date | Description                   |  Amount |
2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:5:|------------+-------------------------------+---------|
2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:6:| 2024-05-09 | Exchange US $1000             | 3759000 |

Where by when I try to click on the file, it is attempting to find wrong
file "2024-05-17-10" instead of "2024-05-17-10:39:33-RCD TEMPORARY
BUFFER.txt" so I guess that regular expression of finding the file in
*grep* temporary buffer shall be improved.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.16.0) of 2024-05-04 built on lco2
Repository revision: fd859fbea2e9d13e76db1c5295d9ddd1c5955d83
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12201009
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-x-toolkit=gtk3'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2
LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: de_DE.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  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 sort mail-extr compile comint ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx emacsbug message mailcap yank-media
puny dired dired-loaddefs 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 cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils 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 inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 67828 12265) (symbols 48 6665 0) (strings 32 17786 1155)
 (string-bytes 1 570370) (vectors 16 10871)
 (vector-slots 8 149772 10737) (floats 8 38 13) (intervals 56 253 0)
 (buffers 984 12))

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Eli Zaretskii]

> From: Jean Louis <bugs@gnu.support>
> Date: Thu, 30 May 2024 13:03:31 +0300
> 
> I have files like:
> 
> ~/tmp/2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt
> 
> and if I do M-x grep on those files, I get results such as:
> 
> 2024-01-22-11:39:12-RCD TEMPORARY BUFFER.txt:13:|            | TOTAL                                      |  -57000 |
> 2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:3:|------------+-------------------------------+---------|
> 2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:4:|       Date | Description                   |  Amount |
> 2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:5:|------------+-------------------------------+---------|
> 2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt:6:| 2024-05-09 | Exchange US $1000             | 3759000 |
> 
> Where by when I try to click on the file, it is attempting to find wrong
> file "2024-05-17-10" instead of "2024-05-17-10:39:33-RCD TEMPORARY
> BUFFER.txt" so I guess that regular expression of finding the file in
> *grep* temporary buffer shall be improved.

Improved how?  Can you suggest how to distinguish between ":39:" and
":13:" in the Grep output, when searching where the file name ends and
the line number and the following test starts?

Do the problems go away if you use "M-x occur" instead?  If so,
perhaps that's a better solution for such file names.

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Jim Porter]

On 6/2/2024 3:02 AM, Eli Zaretskii wrote:
>> From: Jean Louis <bugs@gnu.support>
>> Date: Thu, 30 May 2024 13:03:31 +0300
>>
>> I have files like:
>>
>> ~/tmp/2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt
>>
>> and if I do M-x grep on those files, I get results such as:
[snip]
>> Where by when I try to click on the file, it is attempting to find wrong
>> file "2024-05-17-10" instead of "2024-05-17-10:39:33-RCD TEMPORARY
>> BUFFER.txt" so I guess that regular expression of finding the file in
>> *grep* temporary buffer shall be improved.

Jean: could you show the actual "grep" command that you're using here, 
and the output of "grep --version"? That would help narrow down what's 
going on here.

On 6/2/2024 3:02 AM, Eli Zaretskii wrote:
> Improved how?  Can you suggest how to distinguish between ":39:" and
> ":13:" in the Grep output, when searching where the file name ends and
> the line number and the following test starts?

M-x grep and friends should already be doing the right thing: when 
supported, it passes "--null" to "grep", which changes the output so 
that it separates the file name from the line number using a NUL 
character. The regexps in grep.el can then detect that output and parse 
it correctly.

I tried using a file name like the above, and it all works just fine for 
me. (I'm using GNU grep 3.4.)

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Eli Zaretskii]

> Date: Sun, 2 Jun 2024 21:17:02 -0700
> Cc: 71321@debbugs.gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 6/2/2024 3:02 AM, Eli Zaretskii wrote:
> > Improved how?  Can you suggest how to distinguish between ":39:" and
> > ":13:" in the Grep output, when searching where the file name ends and
> > the line number and the following test starts?
> 
> M-x grep and friends should already be doing the right thing: when 
> supported, it passes "--null" to "grep", which changes the output so 
> that it separates the file name from the line number using a NUL 
> character. The regexps in grep.el can then detect that output and parse 
> it correctly.

I know, but since Jean reported this, his Grep evidently doesn't do
that.  So I asked how to do better in that case.

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Dmitry Gutov]

On 03/06/2024 14:43, Eli Zaretskii wrote:
>> Date: Sun, 2 Jun 2024 21:17:02 -0700
>> Cc:71321@debbugs.gnu.org
>> From: Jim Porter<jporterbugs@gmail.com>
>>
>> On 6/2/2024 3:02 AM, Eli Zaretskii wrote:
>>> Improved how?  Can you suggest how to distinguish between ":39:" and
>>> ":13:" in the Grep output, when searching where the file name ends and
>>> the line number and the following test starts?
>> M-x grep and friends should already be doing the right thing: when
>> supported, it passes "--null" to "grep", which changes the output so
>> that it separates the file name from the line number using a NUL
>> character. The regexps in grep.el can then detect that output and parse
>> it correctly.
> I know, but since Jean reported this, his Grep evidently doesn't do
> that.  So I asked how to do better in that case.

Perhaps he had customized grep-template, so that the --null flag is not 
there.

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Jean Louis]

* Jim Porter <jporterbugs@gmail.com> [2024-06-04 01:43]:
> On 6/2/2024 3:02 AM, Eli Zaretskii wrote:
> > > From: Jean Louis <bugs@gnu.support>
> > > Date: Thu, 30 May 2024 13:03:31 +0300
> > > 
> > > I have files like:
> > > 
> > > ~/tmp/2024-05-17-10:39:33-RCD TEMPORARY BUFFER.txt
> > > 
> > > and if I do M-x grep on those files, I get results such as:
> [snip]
> > > Where by when I try to click on the file, it is attempting to find wrong
> > > file "2024-05-17-10" instead of "2024-05-17-10:39:33-RCD TEMPORARY
> > > BUFFER.txt" so I guess that regular expression of finding the file in
> > > *grep* temporary buffer shall be improved.
> 
> Jean: could you show the actual "grep" command that you're using here, and
> the output of "grep --version"? That would help narrow down what's going on
> here.

$ grep --version

grep (GNU grep) 3.8
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and others; see
<https://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.

Actual grep command is this:

M-x grep RET
grep --color=auto -nH -e '|' *.txt


2024-01-22-11:39:12-RCD TEMPORARY BUFFER.txt:4:|------------+--------------------------------------------+---------|
2024-01-22-11:39:12-RCD TEMPORARY BUFFER.txt:5:| 2024-01-20 | Received from Jean Louis                   |  100000 |
2024-01-22-11:39:12-RCD TEMPORARY BUFFER.txt:6:| 2024-01-22 | Transport to Bukuya                        |  -40000 |



-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Jean Louis]

* Dmitry Gutov <dmitry@gutov.dev> [2024-06-03 23:41]:
> On 03/06/2024 14:43, Eli Zaretskii wrote:
> > > Date: Sun, 2 Jun 2024 21:17:02 -0700
> > > Cc:71321@debbugs.gnu.org
> > > From: Jim Porter<jporterbugs@gmail.com>
> > > 
> > > On 6/2/2024 3:02 AM, Eli Zaretskii wrote:
> > > > Improved how?  Can you suggest how to distinguish between ":39:" and
> > > > ":13:" in the Grep output, when searching where the file name ends and
> > > > the line number and the following test starts?
> > > M-x grep and friends should already be doing the right thing: when
> > > supported, it passes "--null" to "grep", which changes the output so
> > > that it separates the file name from the line number using a NUL
> > > character. The regexps in grep.el can then detect that output and parse
> > > it correctly.
> > I know, but since Jean reported this, his Grep evidently doesn't do
> > that.  So I asked how to do better in that case.
> 
> Perhaps he had customized grep-template, so that the --null flag is not
> there.

grep-template is a variable defined in ‘grep.el’.

Its value is "grep <X> <C> -nH --null -e <R> <F>"
Original value was nil


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Dmitry Gutov]

On 04/06/2024 07:27, Jean Louis wrote:
> Actual grep command is this:
> 
> M-x grep RET
> grep --color=auto -nH -e '|' *.txt

I guess that means that you changed the command by hand when running 
'M-x grep'?

What does the variable grep-command say?

Both grep-command and grep-template are generated in the same place, so 
if one has the --null argument, so should the other.

bug#71321: 30.0.50; M-x grep: not recognizing well files with colon

[Jean Louis]

* Dmitry Gutov <dmitry@gutov.dev> [2024-06-04 13:21]:
> On 04/06/2024 07:27, Jean Louis wrote:
> > Actual grep command is this:
> > 
> > M-x grep RET
> > grep --color=auto -nH -e '|' *.txt
> 
> I guess that means that you changed the command by hand when running 'M-x
> grep'?

Of course, I cannot search without saying what I am searching with the M-x grep command.

> What does the variable grep-command say?

grep-command ➜ "grep --color=auto -nH -e "

> Both grep-command and grep-template are generated in the same place, so if
> one has the --null argument, so should the other.

I did not customize it. Even if I use --null it gives same result.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/