|
From: | Dmitry Gutov |
Subject: | 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 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |