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

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

[Dmitry Gutov]

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

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

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@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".

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

[Dmitry Gutov]

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.

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

[Eli Zaretskii]

> Date: Tue, 03 Feb 2015 03:46:51 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: 19741@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.

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

[Josiah Schwab]

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

Josiah