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

[Eli Zaretskii <eliz@gnu.org>]

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