[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: |
Tue, 03 Feb 2015 20:57:53 +0200 |
> 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.