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

Previous Next

Full log

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.

Previous Next

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