[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19741: 25.0.50; find-tag completion uses an outdated cache of the ta
From: |
Eli Zaretskii |
Subject: |
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@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".