Re: Unified project interface

[Dmitry Gutov]

On 07/27/2015 02:12 PM, Stephen Leake wrote:

> Emacs reads the project file and caches everything. In particular,
> xref-find-definition works nicely.
>
> Now you start to make changes. Some of the files have incorrect syntax,
> or don't compile because of undefined names.
>
> If you attempt to refresh the cache at this point, you will lose _all_
> xref, because of the syntax and name errors.

I thought you were talking about caching the list of files, not their 
contents? The former won't help you with keeping xref-find-definitions 
working.

The latter is a whole different (complex) discussion, largely unrelated 
to the project API. We've touched on it in the thread about hidden buffers.

> On the other hand, the existing cache allows most xref commands to still
> work. So you keep it for a while.

You may be thinking of some cached data somewhere in the implementation 
of the xref backend. That's a valid approach, but neither the project 
API, nor xref API should know anything about it. It's an implementation 
detail.

> This assumes the mechanism that refreshes the cache is sensitive to such
> issues. This is true for the Ada xref backend; it uses the xref info
> output by the compiler, so files must compile. If the file fails to
> compile for any reason, there is no xref info available.

You can keep the xref buffer with the results of the last search, for a 
while, but as you continue editing files, those entries will also begin 
to point at wrong locations.

The exact point at which they stop working will depend on the specific 
implementation of xref-location-marker, though. xref-etags-location is 
designed to be quite resilient, for instance.