GNU bug report logs - #43715
28.0.50; Duplicate results in project-find-regexp

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43715 in the body.
You can then email your comments to 43715 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Pankaj Jangid <pankaj <at> codeisgreat.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Duplicate results in project-find-regexp
Date: Wed, 30 Sep 2020 12:31:36 +0530

I was search a regular expression 'mail' in project ~/.emacs.d. This is
part of the result,

--8<---------------cut here---------------start------------->8---
/Users/pankaj/.emacs.d/lisp/init-email.el
 1: ;;; init-email.el --- configure Email -*- lexical-binding: t -*-
 1: ;;; init-email.el --- configure Email -*- lexical-binding: t -*-
17: ;; (add-hook 'mail-citation-hook 'sc-cite-original)
34: ;;   "Fetch email addresses from the email headers."
34: ;;   "Fetch email addresses from the email headers."
42: (provide 'init-email)
43: ;;; init-email.el ends here
--8<---------------cut here---------------end--------------->8---

Notice the duplicate results from line number 1 and 34.


In GNU Emacs 28.0.50 (build 6, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H2))
 of 2020-09-30 built on BigBook.local
Repository revision: 6c0f1c26d296132e37b2508a00efc73f3df95b0c
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1894
System Description:  Mac OS X 10.15.7

Configured using:
 'configure LDFLAGS=-L/usr/local/opt/ruby/lib
 CPPFLAGS=-I/usr/local/opt/ruby/include
 PKG_CONFIG_PATH=:/usr/local/opt/sqlite/lib/pkgconfig:/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/opt/openssl/lib/pkgconfig:/usr/local/opt/libffi/lib/pkgconfig:/usr/local/opt/ruby/lib/pkgconfig'

Configured features:
JPEG TIFF GIF PNG RSVG DBUS GLIB NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS NS MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_IN.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  electric-pair-mode: t
  show-paren-mode: t
  global-semanticdb-minor-mode: t
  global-semantic-idle-scheduler-mode: t
  semantic-mode: t
  recentf-mode: t
  icomplete-mode: t
  which-key-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail grep cl-extra two-column
iso-transl jka-compr rect vc-mtn vc-hg vc-git diff-mode vc-bzr vc-src
vc-sccs vc-svn vc-cvs vc-rcs vc vc-dispatcher misearch multi-isearch
checkdoc lisp-mnt display-line-numbers elec-pair paren hideshow
semantic/db-mode semantic/idle semantic/analyze semantic/sort
semantic/scope semantic/analyze/fcn semantic/db eieio-base
semantic/format ezimage semantic/tag-ls semantic/find semantic/ctxt
semantic/util-modes semantic/util semantic semantic/tag semantic/lex
semantic/fw mode-local cedet init server vtl cl init-java init-kotlin
init-javascript company js cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs eglot array filenotify
jsonrpc ert ewoc debug backtrace help-mode xref pcase url-util project
imenu init-elisp init-keys init-modeline init-looks init-editorconfig
init-speedbar init-recentf recentf tree-widget wid-edit init-date-time
solar cal-dst init-crypto init-browser init-icomplete icomplete
init-which-key which-key init-flymake flymake-proc flymake compile
warnings init-dired init-org org-indent org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-footnote org-src ob-comint org-pcomplete
pcomplete comint ansi-color ring org-list org-faces org-entities
noutline outline easy-mmode org-version ob-emacs-lisp ob-core ob-eval
org-table ol org-keys org-loaddefs find-func cal-menu calendar
cal-loaddefs org-compat advice org-macs init-erc erc-auth erc-join
erc-goodies erc erc-backend iso8601 thingatpt pp format-spec
erc-loaddefs init-email message rmc puny dired dired-loaddefs rfc822 mml
mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev
mail-utils gmm-utils mailheader init-ibuffer edmacro kmacro info
early-init package easymenu browse-url url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame minibuffer cl-generic 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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 230973 19997)
 (symbols 48 24482 1)
 (strings 32 78131 9692)
 (string-bytes 1 2747741)
 (vectors 16 38606)
 (vector-slots 8 466323 22924)
 (floats 8 446 170)
 (intervals 56 5098 0)
 (buffers 992 18))

-- 
Pankaj Jangid

GnuPG Fingerprint => 0B62 7424 3B26 A911 052A  DDE6 7C95 6E6F F858 7689

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Wed, 30 Sep 2020 15:59:10 +0200

Pankaj Jangid <pankaj <at> codeisgreat.org> writes:

> I was search a regular expression 'mail' in project ~/.emacs.d. This is
> part of the result,
>
> /Users/pankaj/.emacs.d/lisp/init-email.el
>  1: ;;; init-email.el --- configure Email -*- lexical-binding: t -*-
>  1: ;;; init-email.el --- configure Email -*- lexical-binding: t -*-
> 17: ;; (add-hook 'mail-citation-hook 'sc-cite-original)
> 34: ;;   "Fetch email addresses from the email headers."
> 34: ;;   "Fetch email addresses from the email headers."
> 42: (provide 'init-email)
> 43: ;;; init-email.el ends here
>
> Notice the duplicate results from line number 1 and 34.

It looks like when there are two matches in the same line, the line is
listed twice?  So I tried the same command on the Emacs tree (with
"regexp" as the regexp) and, indeed:

 2215: 	that debugger code that needs to do regexp match won't break
 2438: 	Fix regexp-opt documentation (bug #17862)
 2440: 	* lisp/emacs-lisp/regexp-opt.el (regexp-opt):
 2440: 	* lisp/emacs-lisp/regexp-opt.el (regexp-opt):

So it this a feature or a bug?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> linkov.net>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Dmitry Gutov <dgutov <at> yandex.ru>, Pankaj Jangid <pankaj <at> codeisgreat.org>,
 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Wed, 30 Sep 2020 22:25:25 +0300

forcemerge 36967 43715
quit

> So it this a feature or a bug?

In bug#36967 it's labeled as a "drawback".

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Pankaj Jangid <pankaj <at> codeisgreat.org>
Cc: 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Thu, 1 Oct 2020 01:52:49 +0300

On 30.09.2020 16:59, Lars Ingebrigtsen wrote:
> So it this a feature or a bug?

It is both, I guess.

The behavior is less than ideal, but the fix will have to satisfy 
multiple constraints: the xref item creation (taking care of the format 
being backward-compatible), the rendering of them in the buffer, and the 
'xref-query-replace-in-results' command, the implementation of which 
relies on the one-line-per-match property of an xref buffer.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Thu, 01 Oct 2020 03:15:56 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> The behavior is less than ideal, but the fix will have to satisfy
> multiple constraints: the xref item creation (taking care of the
> format being backward-compatible), the rendering of them in the
> buffer, and the 'xref-query-replace-in-results' command, the
> implementation of which relies on the one-line-per-match property of
> an xref buffer.

Right.  I know next to nothing about xref internals...  but...  couldn't
this function just squash the multiple-matches-on-a-single-line into one
line?  Preserving the text props from the multiple lines and whatnot?
So a post-processing step?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Thu, 1 Oct 2020 23:38:01 +0300

On 01.10.2020 04:15, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
>> The behavior is less than ideal, but the fix will have to satisfy
>> multiple constraints: the xref item creation (taking care of the
>> format being backward-compatible), the rendering of them in the
>> buffer, and the 'xref-query-replace-in-results' command, the
>> implementation of which relies on the one-line-per-match property of
>> an xref buffer.
> 
> Right.  I know next to nothing about xref internals...  but...  couldn't
> this function just squash the multiple-matches-on-a-single-line into one
> line?  Preserving the text props from the multiple lines and whatnot?
> So a post-processing step?

Which function?

xref-query-replace-in-results works on an existing xref buffer. And it 
uses the position of point (at the beginning of line) as both user 
indicator and to persist the state of the replacement process.

Going back to xref buffers, if two matches are rendered on one line, 
that leads to a question of how 'n' and 'p' should behave (whether they 
would also jump between the matches on the same line).

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Thu, 01 Oct 2020 22:39:28 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

>> Right.  I know next to nothing about xref internals...  but...
>> couldn't
>> this function just squash the multiple-matches-on-a-single-line into one
>> line?  Preserving the text props from the multiple lines and whatnot?
>> So a post-processing step?
>
> Which function?

`project-find-regexp'

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Fri, 2 Oct 2020 00:28:16 +0300

On 01.10.2020 23:39, Lars Ingebrigtsen wrote:
>>> Right.  I know next to nothing about xref internals...  but...
>>> couldn't
>>> this function just squash the multiple-matches-on-a-single-line into one
>>> line?  Preserving the text props from the multiple lines and whatnot?
>>> So a post-processing step?
>> Which function?
> `project-find-regexp'

Then I'm not sure which eventual behavior you envision. Among other 
things, it doesn't answer the question I asked in the second paragraph 
of my previous email.

And if I get your idea right, this would break 
xref-query-replace-in-results.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Fri, 2 Oct 2020 00:30:57 +0300

Sorry,

On 02.10.2020 00:28, Dmitry Gutov wrote:
> question I asked in the second paragraph of my previous email

                          ^ last

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Thu, 01 Oct 2020 23:38:50 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 01.10.2020 23:39, Lars Ingebrigtsen wrote:
>>>> Right.  I know next to nothing about xref internals...  but...
>>>> couldn't
>>>> this function just squash the multiple-matches-on-a-single-line into one
>>>> line?  Preserving the text props from the multiple lines and whatnot?
>>>> So a post-processing step?
>>> Which function?
>> `project-find-regexp'
>
> Then I'm not sure which eventual behavior you envision. Among other
> things, it doesn't answer the question I asked in the second paragraph
> of my previous email.

This one?

> Going back to xref buffers, if two matches are rendered on one line,
> that leads to a question of how 'n' and 'p' should behave (whether
> they would also jump between the matches on the same line).

I have no idea; I've never used those commands.

I'd just expect project-find-regexp to work as M-x grep, and have
`next-error' work (which works based on lines).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Fri, 2 Oct 2020 00:45:22 +0300

On 02.10.2020 00:38, Lars Ingebrigtsen wrote:

>> Going back to xref buffers, if two matches are rendered on one line,
>> that leads to a question of how 'n' and 'p' should behave (whether
>> they would also jump between the matches on the same line).
> 
> I have no idea; I've never used those commands.
> 
> I'd just expect project-find-regexp to work as M-x grep, and have
> `next-error' work (which works based on lines).

So you think it's a good idea for 'n' and 'p' to skip subsequent matches 
on the line? I'm less sure, but OK.

Then that mostly leaves the question of xref-query-replace-in-results 
and how to retain the information it requires in a backward-compatible way.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: larsi <at> gnus.org, pankaj <at> codeisgreat.org, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Fri, 02 Oct 2020 09:37:02 +0300

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 2 Oct 2020 00:45:22 +0300
> Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
> 
> So you think it's a good idea for 'n' and 'p' to skip subsequent matches 
> on the line?

Please don't: that would be mightily confusing.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, pankaj <at> codeisgreat.org, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Fri, 2 Oct 2020 11:52:49 +0300

On 02.10.2020 09:37, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 2 Oct 2020 00:45:22 +0300
>> Cc: Pankaj Jangid <pankaj <at> codeisgreat.org>, 43715 <at> debbugs.gnu.org
>>
>> So you think it's a good idea for 'n' and 'p' to skip subsequent matches
>> on the line?
> 
> Please don't: that would be mightily confusing.

To play the devil's advocate: this is already what both Grep and Occur 
do. So maybe it is fine?

Or we should fix the other modes.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: larsi <at> gnus.org, pankaj <at> codeisgreat.org, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Fri, 02 Oct 2020 12:18:54 +0300

> Cc: larsi <at> gnus.org, pankaj <at> codeisgreat.org, 43715 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 2 Oct 2020 11:52:49 +0300
> 
> >> So you think it's a good idea for 'n' and 'p' to skip subsequent matches
> >> on the line?
> > 
> > Please don't: that would be mightily confusing.
> 
> To play the devil's advocate: this is already what both Grep and Occur 
> do. So maybe it is fine?
> 
> Or we should fix the other modes.

I'd prefer the latter, of course.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: dgutov <at> yandex.ru
Cc: larsi <at> gnus.org, pankaj <at> codeisgreat.org, 43715 <at> debbugs.gnu.org
Subject: Re: bug#43715: 28.0.50; Duplicate results in project-find-regexp
Date: Fri, 02 Oct 2020 12:52:33 +0300

> Date: Fri, 02 Oct 2020 12:18:54 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: larsi <at> gnus.org, pankaj <at> codeisgreat.org, 43715 <at> debbugs.gnu.org
> 
> > Cc: larsi <at> gnus.org, pankaj <at> codeisgreat.org, 43715 <at> debbugs.gnu.org
> > From: Dmitry Gutov <dgutov <at> yandex.ru>
> > Date: Fri, 2 Oct 2020 11:52:49 +0300
> > 
> > >> So you think it's a good idea for 'n' and 'p' to skip subsequent matches
> > >> on the line?
> > > 
> > > Please don't: that would be mightily confusing.
> > 
> > To play the devil's advocate: this is already what both Grep and Occur 
> > do. So maybe it is fine?
> > 
> > Or we should fix the other modes.
> 
> I'd prefer the latter, of course.

At least by default, that is.  If someone really wants to be able to
skip identical hits, I won't object to having an option for that.  But
having 'n' and 'p' skip by default is unexpected and confusing.

Previous Next

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