* bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table
@ 2015-02-01 19:59 Dmitry Gutov
2015-02-02 17:32 ` Eli Zaretskii
2016-11-26 17:43 ` Josiah Schwab
0 siblings, 2 replies; 5+ messages in thread
From: Dmitry Gutov @ 2015-02-01 19:59 UTC (permalink / raw)
To: 19741
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.
In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.12.2)
of 2015-01-30 on axl
Repository revision: 9242cdcda95e0fcb57233a8665d251e280eddec6
Windowing system distributor `The X.Org Foundation', version 11.0.11601901
System Description: Ubuntu 14.10
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table
2015-02-01 19:59 bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table Dmitry Gutov
@ 2015-02-02 17:32 ` Eli Zaretskii
2015-02-03 1:46 ` Dmitry Gutov
2016-11-26 17:43 ` Josiah Schwab
1 sibling, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2015-02-02 17:32 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 19741
> 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".
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table
2015-02-02 17:32 ` Eli Zaretskii
@ 2015-02-03 1:46 ` Dmitry Gutov
2015-02-03 18:57 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Gutov @ 2015-02-03 1:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 19741
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table
2015-02-03 1:46 ` Dmitry Gutov
@ 2015-02-03 18:57 ` Eli Zaretskii
0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2015-02-03 18:57 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 19741
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table
2015-02-01 19:59 bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table Dmitry Gutov
2015-02-02 17:32 ` Eli Zaretskii
@ 2016-11-26 17:43 ` Josiah Schwab
1 sibling, 0 replies; 5+ messages in thread
From: Josiah Schwab @ 2016-11-26 17:43 UTC (permalink / raw)
To: 19741; +Cc: Dmitry Gutov
I attempted to reproduce this bug using emacs 25.1, but was unable to.
Josiah
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-11-26 17:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-02-01 19:59 bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table Dmitry Gutov
2015-02-02 17:32 ` Eli Zaretskii
2015-02-03 1:46 ` Dmitry Gutov
2015-02-03 18:57 ` Eli Zaretskii
2016-11-26 17:43 ` Josiah Schwab
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).