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

Previous Next

Full log

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".

Previous Next

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