From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Yates Newsgroups: gmane.emacs.devel Subject: Re: Unified project interface Date: Sun, 26 Jul 2015 19:56:52 -0400 Message-ID: References: <557039DB.4060607@yandex.ru> <85d21bbkqf.fsf@stephe-leake.org> <5570E86B.8070200@yandex.ru> <85iob2a2mm.fsf@stephe-leake.org> <55B2CDA4.8020207@yandex.ru> <868ua5caz6.fsf@stephe-leake.org> <55B441DD.9060806@yandex.ru> <86zj2jb1tx.fsf@stephe-leake.org> <55B517AC.5020401@yandex.ru> <86oaiybvbf.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1136515cb77a10051bcffdd0 X-Trace: ger.gmane.org 1437955032 11417 80.91.229.3 (26 Jul 2015 23:57:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jul 2015 23:57:12 +0000 (UTC) Cc: Emacs developers To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 01:57:11 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZJVn3-0005bd-7p for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 01:57:09 +0200 Original-Received: from localhost ([::1]:51136 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJVn2-0001ZC-HM for ged-emacs-devel@m.gmane.org; Sun, 26 Jul 2015 19:57:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJVmp-0001VL-FG for emacs-devel@gnu.org; Sun, 26 Jul 2015 19:56:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJVmn-0001FU-Cn for emacs-devel@gnu.org; Sun, 26 Jul 2015 19:56:55 -0400 Original-Received: from mail-vn0-x22e.google.com ([2607:f8b0:400c:c0f::22e]:33109) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJVmn-0001FH-6K for emacs-devel@gnu.org; Sun, 26 Jul 2015 19:56:53 -0400 Original-Received: by vnav141 with SMTP id v141so25298812vna.0 for ; Sun, 26 Jul 2015 16:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=iexLFgQPk8FkANh2UiJGy9LURFYWCrSquKqss9+6GiI=; b=IB4/r61VLFzyFqW2bizgYWZm45MToPrplaW3IyuEsongiq3ERl3iNuZHFOmF7EJBYJ FURRMiYo/69ifYB60v7MERx75UZ8dcupabdUtsIf7aehLZH6DIEEvRh783ECankDlLH8 cEQNEA/vFj+4ztgA4KLjchLCjhqTfOHOt6LPd5WNviwZ+G4mcj4DI8WBdInVleA3lD3K Y5iJHZSphyb+GqVPd0eRPeBkQeCOIeDB7Ii8vjLyxsoOKJEjNx95jR3rpEh9Ppm1nFLs iJb6be06jY7eJz/knQQePNboFdVMNJkFVrzAhWu3ylSdl3vzGGoBVMBwgTG4U4PK+rAo DRbg== X-Received: by 10.52.83.66 with SMTP id o2mr30919715vdy.26.1437955012391; Sun, 26 Jul 2015 16:56:52 -0700 (PDT) Original-Received: by 10.31.92.130 with HTTP; Sun, 26 Jul 2015 16:56:52 -0700 (PDT) In-Reply-To: <86oaiybvbf.fsf@stephe-leake.org> X-Google-Sender-Auth: RaU5FfKbPQiur9Lyl5fljPodSJQ X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400c:c0f::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188102 Archived-At: --001a1136515cb77a10051bcffdd0 Content-Type: text/plain; charset=UTF-8 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 --001a1136515cb77a10051bcffdd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Jul 26, 2015 at 2:57 PM, Stephen Leake <stephen_leake= @stephe-leake.org> wrote:
<= span class=3D"">> 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; t= hey
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".=C2=A0 I conjecture that you only = advocate such a UI because you imagine a not-particularly performant implem= entation.=C2=A0 If there were no cost to keeping the cache current (equival= ent to stating that a naive user never would _never_ need to learn of that = cache) =C2=A0would you still advocate such a UI?

I= n small projects the cost of a simplistic brute-force change determination = is likely to be entirely acceptable.=C2=A0 On systems that support emacs= 9; file-notify watching every directory within a project should be able to = keep cache refresh overhead to negligible levels (potentially improved by o= nly watch the modifiable portions of the project).

In the exceedingly rare case where a user needs to keep work hidden from p= roject searches he can either modify the project definition to blacklist te= mporarily the areas he wants excluded.=C2=A0 Alternatively we could provide= a toggle for very advanced users to suppress cache refersh.

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

/john

<= /div> --001a1136515cb77a10051bcffdd0--