[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19466: 25.0.50; xref-find-def doesn't find C functions

From: Eli Zaretskii
Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions
Date: Fri, 23 Jan 2015 23:34:05 +0200

> From: Stefan Monnier <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden,  address@hidden
> Date: Fri, 23 Jan 2015 16:15:49 -0500
> >> If xref can reliably deduce that I switched projects and automatically
> >> update its database, that's fine with me, and would probably
> >> constitute what you mean by "dependence on the current file or
> >> project".
> Right, ideally that's what tags.el should do: it should associate
> a "file-system area" to each TAGS file; so it can know automatically
> which TAGS file to use based on default-directory.

It does (try "M-x visit-tags-table" and you will see that the default
it suggests is like you say).  It just doesn't automatically load
TAGS, because the fact that I am in some buffer doesn't yet mean that
I'm working on that buffer's project and need its TAGS.

> Whether it then keeps several TAGS file opened at the same time, or
> whether it only keeps a single-one-at-a-time (and reloads the other
> when you move to a buffer that belongs to a different project) is just
> an implementation detail.

The important part is that it allows me to keep or discard portions of
the tags table.  _That_ is certainly NOT an implementation detail.

> >> Take, for example, the use case where I'm testing a program and found
> >> a bug.  I then need to be able to quickly find and examine the
> >> definition of symbols that might be involved in the bug, look at their
> >> code, perhaps make some changes -- this all will be served well by
> >> using the database (such as TAGS) of that single program.  But suppose
> >> I now come to the conclusion that the bug is not in the program per
> >> se, but involves one of the external libraries it uses.  Now I need to
> >> go through the sources of that library (whose sources, by sheer luck
> >> or maybe something else, I already have available on my system).  How
> >> would xref or etags know whether I switched to that library as part of
> >> my previous work (and therefore still need access to the previous
> >> project's symbols), or because I'm now working on an entirely
> >> different project?
> It wouldn't and it would only give you access to the identifiers of the
> project to which the current-buffer belongs.  So if you use M-. from
> a file in the buggy library it's use the TAGS file of that library, and
> if you then go to a different buffer belonging to your program and use
> M-. xref should then use the TAGS file of that program.  I.e. you tell
> Emacs which TAGS file to use by selecting an appropriate buffer before
> you hit M-.

So you are saying that when I'm in some buffer, I cannot look at some
of the identifiers until I switch to another buffer?  That's very
inconvenient.  Again, when I work on a problem that happens between a
program and a library, I need to see both sides of the interface at
the same time, independently of which buffer I am in.  Conceptually,
the set of identifiers that are relevant to me in this situation is
the union of both projects, and I should be able to find any
identifier from this union no matter which buffer is the current one.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]