bug#47366: 27.1; Tags search (regexp): FAILS

bug#47366: 27.1; Tags search (regexp): FAILS

[Bob Floyd]

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

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))


[-- Attachment #2: Type: text/html, Size: 10119 bytes --]

bug#47366: 27.1; Tags search (regexp): FAILS

[Lars Ingebrigtsen]

"Bob Floyd" <bobfloyd@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

bug#47366: 27.1; Tags search (regexp): FAILS

[Eli Zaretskii]

> Cc: 47366@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 27 Jun 2022 10:24:33 +0200
> 
> "Bob Floyd" <bobfloyd@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.

bug#47366: 27.1; Tags search (regexp): FAILS

[Bob Floyd]

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@gnu.org] 
Sent: Monday, June 27, 2022 4:15 AM
To: Lars Ingebrigtsen
Cc: bobfloyd@comcast.net; 47366@debbugs.gnu.org
Subject: Re: bug#47366: 27.1; Tags search (regexp): FAILS

> Cc: 47366@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 27 Jun 2022 10:24:33 +0200
> 
> "Bob Floyd" <bobfloyd@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.

bug#47366: 27.1; Tags search (regexp): FAILS

[Lars Ingebrigtsen]

"Bob Floyd" <bobfloyd@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