From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Unified project interface Date: Mon, 27 Jul 2015 04:49:04 +0300 Message-ID: <55B58E10.7000306@yandex.ru> 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: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1437961771 5324 80.91.229.3 (27 Jul 2015 01:49:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 01:49:31 +0000 (UTC) Cc: Emacs developers To: John Yates , Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 03:49:26 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 1ZJXXh-0007JK-Ox for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 03:49:26 +0200 Original-Received: from localhost ([::1]:51268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJXXg-0003th-Oz for ged-emacs-devel@m.gmane.org; Sun, 26 Jul 2015 21:49:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJXXU-0003tP-P6 for emacs-devel@gnu.org; Sun, 26 Jul 2015 21:49:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJXXR-0005Kf-Hz for emacs-devel@gnu.org; Sun, 26 Jul 2015 21:49:12 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:33193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJXXR-0005KY-Al for emacs-devel@gnu.org; Sun, 26 Jul 2015 21:49:09 -0400 Original-Received: by wicmv11 with SMTP id mv11so120546603wic.0 for ; Sun, 26 Jul 2015 18:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=Fr51jJJ4NL6AOigoV+xKIFQL1N7MB6qDSNrLM8lpLm8=; b=mC4tpnRJQiC6miKZ9a4O3U6FfDbjox/86CocIcGZ1PzM6ThErltThzO3cxb1bZsRz0 4pABBBOkU3HClXnUjPGSlzHoKk8JvuFscCMkvSZCvlyw/6CZU07u4zgNcPQDz9o5XLv0 CxBh6XEvmbQsRIPq9aBYWztK9Pg7SC0A5P0j1mc+ethNxMi2rEsoQMKiwgScMd8dVAPd M91zsU3M/6P1jXeKRcj9u+UGCfsM6wNT6BAk60YIQIGqmjTRc0j75CRUManY0lPmsvNz i5NvSLH2IiWbk+DliPUwzVfaWp1qVawlgZyEgfceq5fUcucGdvjUQ9NH7V+NOioYefN0 rplw== X-Received: by 10.180.19.36 with SMTP id b4mr18389706wie.33.1437961748534; Sun, 26 Jul 2015 18:49:08 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id bm9sm10911158wib.10.2015.07.26.18.49.07 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2015 18:49:07 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 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:188104 Archived-At: On 07/27/2015 02:56 AM, John Yates wrote: > 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? I think the word "cache" itself implies a storage that can get stale. > 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. Right. Even if there's a cache mechanism, I'd very much like to see its invalidation by automatic means (via file-notify, or similar), at least by default. Anyway, I'd prefer to implement as many operations as feasible without needing that cache. If the search through the project tree spends an order of magnitude more time searching than listing the files, there's not point in caching the latter.