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

[Dmitry Gutov <dgutov@yandex.ru>]

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

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.

etagggggsss.

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.