GNU bug report logs - #19741
25.0.50; find-tag completion uses an outdated cache of the tags table

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 19741 in the body.
You can then email your comments to 19741 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: Dmitry Gutov <dgutov <at> yandex.ru>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.50; find-tag completion uses an outdated cache of the tags table
Date: Sun, 01 Feb 2015 21:59:10 +0200

1. M-x find-file lisp/progmodes/etags.el. Being in that buffer, and not
in *scratch*, is somehow important.

2. M-x visit-tags-table ../../lisp/TAGS.

3. M-x find-tag, press TAB, see the table loaded.

4. M-x visit-tags-table, ../../src/TAGS, press `y' (important!).

5. M-x find-tag, type `display_li', press TAB, see [No matches]!

The main scenario ends here.

6. Finish typing `display_line', press RET, see the navigation succeed
anyway (with a jump to src/xdisp.c:20013).

7. Press `M-,' to get back to etags.el, repeat 5., see the same result.

8. M-x find-file ../../src/search.c, repeat 5., see a different result.

In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
 of 2015-01-30 on axl
Repository revision: 9242cdcda95e0fcb57233a8665d251e280eddec6
Windowing system distributor `The X.Org Foundation', version 11.0.11601901
System Description:	Ubuntu 14.10

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19741 <at> debbugs.gnu.org
Subject: Re: bug#19741: 25.0.50;
 find-tag completion uses an outdated cache of the tags table
Date: Mon, 02 Feb 2015 19:32:13 +0200

> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sun, 01 Feb 2015 21:59:10 +0200
> 
> 1. M-x find-file lisp/progmodes/etags.el. Being in that buffer, and not
> in *scratch*, is somehow important.
> 
> 2. M-x visit-tags-table ../../lisp/TAGS.
> 
> 3. M-x find-tag, press TAB, see the table loaded.
> 
> 4. M-x visit-tags-table, ../../src/TAGS, press `y' (important!).
> 
> 5. M-x find-tag, type `display_li', press TAB, see [No matches]!
> 
> The main scenario ends here.
> 
> 6. Finish typing `display_line', press RET, see the navigation succeed
> anyway (with a jump to src/xdisp.c:20013).
> 
> 7. Press `M-,' to get back to etags.el, repeat 5., see the same result.
> 
> 8. M-x find-file ../../src/search.c, repeat 5., see a different result.

I think this happens because visiting the second TAGS table doesn't
invalidate or recalculate tags-completion-table, which was generated
when you pressed TAB at the first find-tag prompt.  Look at the
function tags-completion-table, it does this:

  (defun tags-completion-table ()
    "Build `tags-completion-table' on demand.
  The tags included in the completion table are those in the current
  tags table and its (recursively) included tags tables."
    (or tags-completion-table
	;; No cached value for this buffer.

IOW, it reuses the existing value of tags-completion-table (the
variable).  However, visiting the second TAGS table didn't update the
completion table, so you get "No match".

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 19741 <at> debbugs.gnu.org
Subject: Re: bug#19741: 25.0.50; find-tag completion uses an outdated
 cache of the tags table
Date: Tue, 03 Feb 2015 03:46:51 +0200

On 02/02/2015 07:32 PM, Eli Zaretskii wrote:

> I think this happens because visiting the second TAGS table doesn't
> invalidate or recalculate tags-completion-table, which was generated
> when you pressed TAB at the first find-tag prompt.  Look at the
> function tags-completion-table, it does this:
>
>    (defun tags-completion-table ()
>      "Build `tags-completion-table' on demand.
>    The tags included in the completion table are those in the current
>    tags table and its (recursively) included tags tables."
>      (or tags-completion-table
> 	;; No cached value for this buffer.

Seems so, but should the `tags-completion-table' value in the lisp/TAGS 
buffer really include the entries from the other currently visited tables?

Looking at `visit-tags-table' signature, some buffers might only have 
the above in the local `tags-file-name' value, whereas others might use 
`tags-table-list'.

Furthermore, lisp/TAGS doesn't include src/TAGS (it's the other way 
around), so `tags-completion-table' variable, judging by the above 
docstring, should only store its tags. Even when there are no 
buffer-local values involved.

> IOW, it reuses the existing value of tags-completion-table (the
> variable).  However, visiting the second TAGS table didn't update the
> completion table, so you get "No match".

See above.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19741 <at> debbugs.gnu.org
Subject: Re: bug#19741: 25.0.50;
 find-tag completion uses an outdated cache of the tags table
Date: Tue, 03 Feb 2015 20:57:53 +0200

> Date: Tue, 03 Feb 2015 03:46:51 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 19741 <at> debbugs.gnu.org
> 
> On 02/02/2015 07:32 PM, Eli Zaretskii wrote:
> 
> > I think this happens because visiting the second TAGS table doesn't
> > invalidate or recalculate tags-completion-table, which was generated
> > when you pressed TAB at the first find-tag prompt.  Look at the
> > function tags-completion-table, it does this:
> >
> >    (defun tags-completion-table ()
> >      "Build `tags-completion-table' on demand.
> >    The tags included in the completion table are those in the current
> >    tags table and its (recursively) included tags tables."
> >      (or tags-completion-table
> > 	;; No cached value for this buffer.
> 
> Seems so, but should the `tags-completion-table' value in the lisp/TAGS 
> buffer really include the entries from the other currently visited tables?

No, it shouldn't.  The problem is that tags-completion-table in
src/TAGS buffer remains nil.

It could be that the problem is in the heuristics employed by
visit-tags-table-buffer, when it needs to intuit what TAGS table to
use.  It does, for example, things like

		;; Third, look for a tags table that contains tags for the
		;; current buffer's file.  If one is found, the lists will
		;; be frobnicated, and CONT will be set non-nil so we don't
		;; do it below.
		(and buffer-file-name
		     (or
		      ;; First check only tables already in buffers.
		      (tags-table-including buffer-file-name t)
		      ;; Since that didn't find any, now do the
		      ;; expensive version: reading new files.
		      (tags-table-including buffer-file-name nil)))

which might explain why staying in etags.el produces the buggy
behavior.

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

From: Josiah Schwab <jschwab <at> gmail.com>
To: 19741 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#19741: 25.0.50;
 find-tag completion uses an outdated cache of the tags table
Date: Sat, 26 Nov 2016 09:43:29 -0800

I attempted to reproduce this bug using emacs 25.1, but was unable to.

Josiah

Previous Next

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