[Top][All Lists]

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

Re: Unified project interface

From: Dmitry Gutov
Subject: Re: Unified project interface
Date: Mon, 27 Jul 2015 14:27:37 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0

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.

reply via email to

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