GNU bug report logs -
#47366
27.1; Tags search (regexp): FAILS
Previous Next
Reported by: "Bob Floyd" <bobfloyd <at> comcast.net>
Date: Wed, 24 Mar 2021 20:11:02 UTC
Severity: normal
Tags: moreinfo
Found in version 27.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 47366 in the body.
You can then email your comments to 47366 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47366
; Package
emacs
.
(Wed, 24 Mar 2021 20:11:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Bob Floyd" <bobfloyd <at> comcast.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 24 Mar 2021 20:11:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
When I do a "tags-search FooFoo" sometimes the search stops in a buffer at
the wrong line. FooFoo is indeed in the buffer, but can be many lines away
from where emacs stopped. If I "kill-buffer" (C-x k) and restart the
"tags-search" then emacs stops at the correct line where FooFoo is. I think
this happens when I do a "tags-search", make edits in the buffer, then
"save-some-buffers" (C-x s) followed by a 2nd "tags-search" that then fails.
It appears maybe that the regex compiler isn't run after the edits?
Sorry I can't provide an exact sequence of commands for you to see it, it
doesn't happen always (maybe it doesn't even stop in the buffer and I don't
notice), but perhaps you can recognize the issue.
Thanks,
Bob Floyd
In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
of 2020-08-21 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.19042.867)
Recent messages:
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/ngnutmeg.c...
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/ngproc2mod.c...
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/ngsconvert.c...
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/ngspice.c...
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/sharedspice.c...
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/tclspice.c...
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/winmain.c...
Scanning file d:/Bob/cvs/apps/ngspice-34/ngspice-34/src/winmain.h...
user-error: All files processed
Beginning of buffer
Configured using:
'configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
Major mode: Info
Minor modes in effect:
shell-dirtrack-mode: t
show-paren-mode: t
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
menu-bar-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:
d:/Bob/.emacs.d/elpa/verilog-mode-2020.6.27.14326051/verilog-mode hides
c:/Program
Files/Emacs-27.1/x86_64/share/emacs/27.1/lisp/progmodes/verilog-mode
Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils mule-util pulse thingatpt etags fileloop
generator xref project sh-script smie executable misearch multi-isearch
dired-aux dired dired-loaddefs time-date pcmpl-unix web-mode advice
derived edmacro kmacro shell pcomplete comint ansi-color ring printing
ps-print ps-print-loaddefs ps-def lpr paren cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs finder-inf
tex-site info 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 dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars 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 loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote threads w32notify w32
lcms2 multi-tty make-network-process emacs)
Memory information:
((conses 16 367571 20618)
(symbols 48 16568 1)
(strings 32 59350 11795)
(string-bytes 1 1919672)
(vectors 16 23992)
(vector-slots 8 353922 22828)
(floats 8 314 304)
(intervals 56 27804 2209)
(buffers 1000 74))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47366
; Package
emacs
.
(Mon, 27 Jun 2022 08:25:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 47366 <at> debbugs.gnu.org (full text, mbox):
"Bob Floyd" <bobfloyd <at> comcast.net> writes:
> When I do a “tags-search FooFoo” sometimes the search stops in a
> buffer at the wrong line. FooFoo is indeed in the buffer, but can be
> many lines away from where emacs stopped. If I “kill-buffer” (C-x k)
> and restart the “tags-search” then emacs stops at the correct line
> where FooFoo is. I think this happens when I do a “tags-search”, make
> edits in the buffer, then “save-some-buffers” (C-x s) followed by a
> 2nd “tags-search” that then fails.
>
> It appears maybe that the regex compiler isn’t run after the edits?
>
> Sorry I can’t provide an exact sequence of commands for you to see it,
> it doesn’t happen always (maybe it doesn’t even stop in the buffer and
> I don’t notice), but perhaps you can recognize the issue.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I tried reproducing this in Emacs 29, but was unable to. But I'm not
sure I'm testing the right thing.
Do you still see this problem in recent Emacs versions? If so, could
you try to come up with a complete recipe to reproduce the problem?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 27 Jun 2022 08:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47366
; Package
emacs
.
(Mon, 27 Jun 2022 11:16:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 47366 <at> debbugs.gnu.org (full text, mbox):
> Cc: 47366 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 27 Jun 2022 10:24:33 +0200
>
> "Bob Floyd" <bobfloyd <at> comcast.net> writes:
>
> > When I do a “tags-search FooFoo” sometimes the search stops in a
> > buffer at the wrong line. FooFoo is indeed in the buffer, but can be
> > many lines away from where emacs stopped. If I “kill-buffer” (C-x k)
> > and restart the “tags-search” then emacs stops at the correct line
> > where FooFoo is. I think this happens when I do a “tags-search”, make
> > edits in the buffer, then “save-some-buffers” (C-x s) followed by a
> > 2nd “tags-search” that then fails.
> >
> > It appears maybe that the regex compiler isn’t run after the edits?
> >
> > Sorry I can’t provide an exact sequence of commands for you to see it,
> > it doesn’t happen always (maybe it doesn’t even stop in the buffer and
> > I don’t notice), but perhaps you can recognize the issue.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I tried reproducing this in Emacs 29, but was unable to. But I'm not
> sure I'm testing the right thing.
It is not clear from the recipe whether the OP re-runs etags to
regenerate the TAGS file after making significant changes top the
source files. If etags is not re-run, the TAGS file could be outdated
more than the slack we allow, and then the problem description would
make sense.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47366
; Package
emacs
.
(Mon, 27 Jun 2022 15:08:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 47366 <at> debbugs.gnu.org (full text, mbox):
I have not had this issue after compiling:
This is GNU Emacs 28.0.50 (build 1, x86_64-w64-mingw32)
of 2021-08-09
I've been using it since then.
Thanks,
Bob
-----Original Message-----
From: Eli Zaretskii [mailto:eliz <at> gnu.org]
Sent: Monday, June 27, 2022 4:15 AM
To: Lars Ingebrigtsen
Cc: bobfloyd <at> comcast.net; 47366 <at> debbugs.gnu.org
Subject: Re: bug#47366: 27.1; Tags search (regexp): FAILS
> Cc: 47366 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Mon, 27 Jun 2022 10:24:33 +0200
>
> "Bob Floyd" <bobfloyd <at> comcast.net> writes:
>
> > When I do a �tags-search FooFoo� sometimes the search stops in a
> > buffer at the wrong line. FooFoo is indeed in the buffer, but can be
> > many lines away from where emacs stopped. If I �kill-buffer� (C-x k)
> > and restart the �tags-search� then emacs stops at the correct line
> > where FooFoo is. I think this happens when I do a �tags-search�, make
> > edits in the buffer, then �save-some-buffers� (C-x s) followed by a
> > 2nd �tags-search� that then fails.
> >
> > It appears maybe that the regex compiler isn�t run after the edits?
> >
> > Sorry I can�t provide an exact sequence of commands for you to see it,
> > it doesn�t happen always (maybe it doesn�t even stop in the buffer and
> > I don�t notice), but perhaps you can recognize the issue.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I tried reproducing this in Emacs 29, but was unable to. But I'm not
> sure I'm testing the right thing.
It is not clear from the recipe whether the OP re-runs etags to
regenerate the TAGS file after making significant changes top the
source files. If etags is not re-run, the TAGS file could be outdated
more than the slack we allow, and then the problem description would
make sense.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#47366
; Package
emacs
.
(Mon, 27 Jun 2022 15:18:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 47366 <at> debbugs.gnu.org (full text, mbox):
"Bob Floyd" <bobfloyd <at> comcast.net> writes:
> I have not had this issue after compiling:
>
> This is GNU Emacs 28.0.50 (build 1, x86_64-w64-mingw32)
> of 2021-08-09
>
> I've been using it since then.
Thanks; I'm closing this bug report, then.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
47366 <at> debbugs.gnu.org and "Bob Floyd" <bobfloyd <at> comcast.net>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Mon, 27 Jun 2022 15:18:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 26 Jul 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 268 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.