Re: Unified project interface

[Stephen Leake <stephen_leake@stephe-leake.org>]

John Yates <john@yates-sheets.org> writes:

> On Sun, Jul 26, 2015 at 2:57 PM, Stephen Leake <
> stephen_leake@stephe-leake.org> wrote:
>
>> > And then the user creates a new dir (or switches to a different
>> > branch, revision, etc), and the cache goes out of sync. How do we
>> > handle that?
>>
>> project-cache-refresh. Only the user knows when it should be done; they
>> may want to keep the slightly out of date cache because something isn't
>> finished with the edits yet.
>
>
> This seems to me to be "rationalizing a zit".  I conjecture that you only
> advocate such a UI because you imagine a not-particularly performant
> implementation.  If there were no cost to keeping the cache current
> (equivalent to stating that a naive user never would _never_ need to learn
> of that cache)  would you still advocate such a UI?

The use case is this:

You have checked out a fully working workspace, in order to do some
refactoring.

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.

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


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.

It is also true that the user time penalty for refreshing the cache is
significant for Ada mode, and grows with the size of the project.

> In small projects the cost of a simplistic brute-force change determination
> is likely to be entirely acceptable.  

Yes, that's true, especially if the cache builder handles syntax errors
gracefully, and is very fast. So that should be one option.

> In the exceedingly rare case where a user needs to keep work hidden from
> project searches he can either modify the project definition to blacklist
> temporarily the areas he wants excluded.  

That's a different use case than I'm talking about, and one I've never
run across; can you elaborate?

I guess that's one way to implement "find-replace in this subset of the
project files".

> Alternatively we could provide a toggle for very advanced users to
> suppress cache refresh.

Yes, that's what I'd like.

> Bottom line: start by getting the model of state and the UI right.  After
> that if the performance in corner cases needs help then give advanced users
> tools to tune the system.  But please do not foist a user-maintained cache
> on casual users.

Yes, good approach.

-- 
-- Stephe