[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: Dmitry Gutov
Subject: bug#19466: 25.0.50; xref-find-def doesn't find C functions
Date: Sat, 24 Jan 2015 18:47:46 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0

On 01/24/2015 11:40 AM, Eli Zaretskii wrote:

To cut this part of discussion short, yes, the project system can well
be designed so that the "current project" depends not on the current
buffer but on the user's choice. So to switch between projects, you
invoke an explicit command, but don't visit a buffer belonging to the
other project. And xref can work with such a system (just as it works
with etags) without significant problems.

Can you tell how can this be set up with xref, or point me to the
relevant documentation?

I did. "Just like it works with etags" was a big hint in the quote above.

I said I will -- when I have time.  I didn't have that time yet,

Please respond after you've found that time, then. Is it is, the current discussion is getting nowhere.

I believe you it's the easiest approach.  But that doesn't yet make it
viable, because IMO it doesn't scale.  Only very simple projects will
be happy with such a design.  The example I described is not very
complicated, either, but it already bumps into this limitation.  I
think this is a clear sign that the limitation should be lifted.

Just for the sake of the argument: instead of visiting two tag tables at the same time from Emacs, you could instead include the external library's tag file in the application's tag file ("--include" etags argument). That doesn't seem like it'll work with several external libraries, but maybe it should.

That wouldn't allow you to jump from a library file to the application's file (I think; you'd have to use e.g. switch-buffer instead), but there is a certain semantic strictness in that (the library doesn't know about the application).

However, it sounds like xref is not yet ready for that, either, is it?
If so, I suggest to add these simple features, because that would
allow to lift the limitation and make the feature much more scalable.

It's quite ready. xref will work with any such backend.

Then there should be a projectile-add-project and
projectile-remove-project as well.  I'm sure someone already thought
about that.

Maybe they didn't but they haven't shared that with the rest of us. Given Projectile's current behavior, though it would cause incompatibility or complications in the implementation.

But anyway, I think I'm starting to like the idea of this approach. Maybe I'll try to implement it sometime.

(I know nothing about Projectile, except that I think the
name is unfortunate -- take this from someone who has an intimate
familiarity with real projectiles.)

I think it's fine. A projectile is not necessarily an ammo round.

That is, a backend can use this approach as well.

"Can" and "does" have a large gap between them, from the user's POV.
Do we already have such a backend?  If not, I suggest to add it.


Its only drawback, from your standpoint, stems from it being the default one (which major modes can override), instead from being assigned in a globalized minor mode.

I'm not sure if we want to have it both as default, and have a minor mode (a by-default-on minor mode won't be good enough).

> I'm here merely as a user, providing feedback for features someone
> else develops.  I hope this is helpful; if not, feel free to
> discontinue the discussion at any point you like.

I you were just a user, I'd have stopped a while ago, since I still don't think this feature request is useful to the majority of users.

Since you're a valued core contributor, though, I'd really like to accommodate your needs. However, that comes with the expectation that you can participate in the design and provide more nuanced requirements than an ordinary user would do. Maybe you'd a least look at the code, if not implement the improvements yourself.

So perhaps some users, like myself, will benefit from preventing the
override?  Is that possible with the current master?

Yes: you use the snippets I provided together with the current master. Whether any part of them is worthy of installing into master, is yet to be determined.

Maybe I am, I don't know.  I don't care how this is called.  What I do
care is to be able to start working on a project with minimal fuss.
Having to spend a significant time telling Emacs just what constitutes
the project is therefore a turn-off: it is why I dislike Visual Studio
like "projects" and "solutions" system -- it might be OK for starting
a project from scratch, but sucks when you need to work on an existing
project, let alone a large one.

I'm pretty sure some users would consider having to call visit-tags-table as "having to spend time telling Emacs just what constitutes a project", as opposed to Projectile's current approach.

It is a very much related discussion, since you think the features I
miss in xref should be implemented by "project support".

No: the xref features should work with etags without additional infrastructure. We won't know that for certain, though, until you find that free time.

I mentioned project support, which we don't have, because you've expanded the discussion to supporting "this mode of work" in different languages and, I'm assuming, for different features. And not every language/framework ecosystem considers the tag files to be the best solution for code navigation, completion, etc.

I'll respond to the rest of this email in a separate thread, but that discussion is likely premature.

etags seems to seamlessly let me have that.  So if xref is meant to
replace etags, it should provide the same functionality, and if that
requires some rudimentary "project support", we should include it when
we announce deprecation of etags.

xref is meant to replace `find-tag' and `tags-apropos'. etags, as a package, is unlikely to ever be deprecated.

reply via email to

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