[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: |
Dmitry Gutov |
Subject: |
bug#19466: 25.0.50; xref-find-def doesn't find C functions |
Date: |
Fri, 23 Jan 2015 19:34:45 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0 |
On 01/23/2015 11:03 AM, Eli Zaretskii wrote:
Most, if not all, projects I work on aren't "projects" in your sense
of the word, I think -- they lack any "project" files except the
sources and Makefile's.
A top Makefile is enough for me, conceptually.
With etags, I switch "projects" by invoking
visit-tags-table and typing a name of a different TAGS file (I'm then
given a choice of whether to keep the previous TAGS table or discard
it, which is important -- see below).
I would consider this you adapting to Emacs's lack of support for
projects: many people like to have commands that work on the "current
project" (find-file, replace, etc), and depend on which buffer you're
currently in. But anyway...
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".
There's no single database. If you're using the etags backend, it should
be just as affected by `M-x visit-tags-table', as `find-tag' is. So that
should be good enough.
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? What if investigating the bug needs to
intermittently look at the sources of the program and the library
(e.g., because the bug happens due to some incompatibility between
them)?
Honestly, I would probably run two instances of Emacs. But the
tags-file-name/tags-table-list approach should still work, as long as
the etags backend is used.
Note that currently the only thing that depends on a specific buffer is
the backend used. And the only buffers that use the non-default value
now are in emacs-lisp-mode or its derivatives.
Until that changes, applying either of the code samples I presented
should give you find-tag-ish behavior everywhere. So I was a bit too
alarmist about you having to use find-file-hook and different major mode
hooks.... yet.
So I think there will always be a need for asking the user about this,
and in addition there are projects without "project" infrastructure,
where xref or etags or any similar feature will have to rely on the
user for telling them which database of symbols to use.
A project infrastructure should take priority over this. For instance,
how the current Projectile users switch to a file in a "different
project"? They call `M-x projectile-switch-project', pick one from the
cached list of projects, and then `M-x projectile-find-file' in the
resulting buffer. I believe this kind of workflow scales better.
The logic behind determining the current project is entirely
configurable, so there's no reason why a directory with a Makefile can't
be considered a project, if the user is so inclined.
Is xref ready for these use cases? If so, in what form (simple
variable customizations, specified commands, Lisp code that the use
must supply, something else) can the user specify what she wants?
If they really want to, using simple functions and major mode hooks.
Maybe minor modes. As you've seen, the code to "get back to using etags"
is trivial.
Would it not depend on major mode at all, so it would also be true
in help-mode and similar buffers?
Sometimes, I guess. Like doing that in *scratch* after "emacs -Q", or
in the *Help* buffer (which sometimes refers to external library
functions).
Right. You'll only need to worry about help-mode buffers after someone
writes dedicated xref support for it, and if you want to ignore their
effors (just like it seems elisp-xref-find is not valuable for you).
Is it possible to turn on xref-etags-mode (or its equivalents)
globally?
It's "turned on" by default. All it does is restore the default values
of two variables, to get back to the default behavior in emacs-lisp-mode
buffers.
(I don't understand why this is not blindingly obvious from looking at
those several lines.)
Are there any disadvantages of that?
The find-func package is generally considered better and easier for
Emacs Lisp navigation than etags. It's more precise, it distinguishes
between different kinds of symbols, AND it can easily visit definitions
from third-party code loaded in user's Emacs.
The one downside (it won't offer non-autoloaded symbols from not loaded
packages) doesn't seems to be a real problem in practice.
Compared to etags, it also won't jump to the C functions that are not
exposed to Emacs Lisp. The overwhelming majority of our users (myself
probably included), won't ever need this.
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, (continued)
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, martin rudalics, 2015/01/22
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/19
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/19
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/20
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/20
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/21
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/21
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/22
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/22
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/23
- bug#19466: 25.0.50; xref-find-def doesn't find C functions,
Dmitry Gutov <=
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/23
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/23
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/24
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/24
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/31
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/31
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Stefan Monnier, 2015/01/23
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/23
- bug#19466: 25.0.50; xref-find-def doesn't find C functions, Eli Zaretskii, 2015/01/16
bug#19466: 25.0.50; xref-find-def doesn't find C functions, Dmitry Gutov, 2015/01/04