* bug#43715: 28.0.50; Duplicate results in project-find-regexp
@ 2020-09-30 7:01 Pankaj Jangid
2020-09-30 13:59 ` Lars Ingebrigtsen
0 siblings, 1 reply; 15+ messages in thread
From: Pankaj Jangid @ 2020-09-30 7:01 UTC (permalink / raw)
To: 43715
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-09-30 7:01 bug#43715: 28.0.50; Duplicate results in project-find-regexp Pankaj Jangid
@ 2020-09-30 13:59 ` Lars Ingebrigtsen
2020-09-30 19:25 ` Juri Linkov
2020-09-30 22:52 ` Dmitry Gutov
0 siblings, 2 replies; 15+ messages in thread
From: Lars Ingebrigtsen @ 2020-09-30 13:59 UTC (permalink / raw)
To: Pankaj Jangid; +Cc: 43715, Dmitry Gutov
Pankaj Jangid <pankaj@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-09-30 13:59 ` Lars Ingebrigtsen
@ 2020-09-30 19:25 ` Juri Linkov
2020-09-30 22:52 ` Dmitry Gutov
1 sibling, 0 replies; 15+ messages in thread
From: Juri Linkov @ 2020-09-30 19:25 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 43715, Pankaj Jangid, Dmitry Gutov
forcemerge 36967 43715
quit
> So it this a feature or a bug?
In bug#36967 it's labeled as a "drawback".
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-09-30 13:59 ` Lars Ingebrigtsen
2020-09-30 19:25 ` Juri Linkov
@ 2020-09-30 22:52 ` Dmitry Gutov
2020-10-01 1:15 ` Lars Ingebrigtsen
1 sibling, 1 reply; 15+ messages in thread
From: Dmitry Gutov @ 2020-09-30 22:52 UTC (permalink / raw)
To: Lars Ingebrigtsen, Pankaj Jangid; +Cc: 43715
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-09-30 22:52 ` Dmitry Gutov
@ 2020-10-01 1:15 ` Lars Ingebrigtsen
2020-10-01 20:38 ` Dmitry Gutov
0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-01 1:15 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Pankaj Jangid, 43715
Dmitry Gutov <dgutov@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-01 1:15 ` Lars Ingebrigtsen
@ 2020-10-01 20:38 ` Dmitry Gutov
2020-10-01 20:39 ` Lars Ingebrigtsen
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Gutov @ 2020-10-01 20:38 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Pankaj Jangid, 43715
On 01.10.2020 04:15, Lars Ingebrigtsen wrote:
> Dmitry Gutov <dgutov@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).
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-01 20:38 ` Dmitry Gutov
@ 2020-10-01 20:39 ` Lars Ingebrigtsen
2020-10-01 21:28 ` Dmitry Gutov
0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-01 20:39 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Pankaj Jangid, 43715
Dmitry Gutov <dgutov@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-01 20:39 ` Lars Ingebrigtsen
@ 2020-10-01 21:28 ` Dmitry Gutov
2020-10-01 21:30 ` Dmitry Gutov
2020-10-01 21:38 ` Lars Ingebrigtsen
0 siblings, 2 replies; 15+ messages in thread
From: Dmitry Gutov @ 2020-10-01 21:28 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Pankaj Jangid, 43715
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-01 21:28 ` Dmitry Gutov
@ 2020-10-01 21:30 ` Dmitry Gutov
2020-10-01 21:38 ` Lars Ingebrigtsen
1 sibling, 0 replies; 15+ messages in thread
From: Dmitry Gutov @ 2020-10-01 21:30 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Pankaj Jangid, 43715
Sorry,
On 02.10.2020 00:28, Dmitry Gutov wrote:
> question I asked in the second paragraph of my previous email
^ last
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-01 21:28 ` Dmitry Gutov
2020-10-01 21:30 ` Dmitry Gutov
@ 2020-10-01 21:38 ` Lars Ingebrigtsen
2020-10-01 21:45 ` Dmitry Gutov
1 sibling, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2020-10-01 21:38 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Pankaj Jangid, 43715
Dmitry Gutov <dgutov@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
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-01 21:38 ` Lars Ingebrigtsen
@ 2020-10-01 21:45 ` Dmitry Gutov
2020-10-02 6:37 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Gutov @ 2020-10-01 21:45 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Pankaj Jangid, 43715
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-01 21:45 ` Dmitry Gutov
@ 2020-10-02 6:37 ` Eli Zaretskii
2020-10-02 8:52 ` Dmitry Gutov
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2020-10-02 6:37 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: larsi, pankaj, 43715
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 2 Oct 2020 00:45:22 +0300
> Cc: Pankaj Jangid <pankaj@codeisgreat.org>, 43715@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-02 6:37 ` Eli Zaretskii
@ 2020-10-02 8:52 ` Dmitry Gutov
2020-10-02 9:18 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Gutov @ 2020-10-02 8:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, pankaj, 43715
On 02.10.2020 09:37, Eli Zaretskii wrote:
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Fri, 2 Oct 2020 00:45:22 +0300
>> Cc: Pankaj Jangid <pankaj@codeisgreat.org>, 43715@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-02 8:52 ` Dmitry Gutov
@ 2020-10-02 9:18 ` Eli Zaretskii
2020-10-02 9:52 ` Eli Zaretskii
0 siblings, 1 reply; 15+ messages in thread
From: Eli Zaretskii @ 2020-10-02 9:18 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: larsi, pankaj, 43715
> Cc: larsi@gnus.org, pankaj@codeisgreat.org, 43715@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#43715: 28.0.50; Duplicate results in project-find-regexp
2020-10-02 9:18 ` Eli Zaretskii
@ 2020-10-02 9:52 ` Eli Zaretskii
0 siblings, 0 replies; 15+ messages in thread
From: Eli Zaretskii @ 2020-10-02 9:52 UTC (permalink / raw)
To: dgutov; +Cc: larsi, pankaj, 43715
> Date: Fri, 02 Oct 2020 12:18:54 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, pankaj@codeisgreat.org, 43715@debbugs.gnu.org
>
> > Cc: larsi@gnus.org, pankaj@codeisgreat.org, 43715@debbugs.gnu.org
> > From: Dmitry Gutov <dgutov@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.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2020-10-02 9:52 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-30 7:01 bug#43715: 28.0.50; Duplicate results in project-find-regexp Pankaj Jangid
2020-09-30 13:59 ` Lars Ingebrigtsen
2020-09-30 19:25 ` Juri Linkov
2020-09-30 22:52 ` Dmitry Gutov
2020-10-01 1:15 ` Lars Ingebrigtsen
2020-10-01 20:38 ` Dmitry Gutov
2020-10-01 20:39 ` Lars Ingebrigtsen
2020-10-01 21:28 ` Dmitry Gutov
2020-10-01 21:30 ` Dmitry Gutov
2020-10-01 21:38 ` Lars Ingebrigtsen
2020-10-01 21:45 ` Dmitry Gutov
2020-10-02 6:37 ` Eli Zaretskii
2020-10-02 8:52 ` Dmitry Gutov
2020-10-02 9:18 ` Eli Zaretskii
2020-10-02 9:52 ` Eli Zaretskii
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).