Re: Unified project interface

[John Yates]

On Sun, Jul 26, 2015 at 2:57 PM, Stephen Leake <address@hidden> 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?

In small projects the cost of a simplistic brute-force change determination is likely to be entirely acceptable.  On systems that support emacs' file-notify watching every directory within a project should be able to keep cache refresh overhead to negligible levels (potentially improved by only watch the modifiable portions of the project).

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.  Alternatively we could provide a toggle for very advanced users to suppress cache refersh.

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.

/john