Re: Unified project interface

[John Yates <john@yates-sheets.org>]

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

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?

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

[-- Attachment #2: Type: text/html, Size: 2190 bytes --]