From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: Unified project interface Date: Mon, 27 Jul 2015 06:12:57 -0500 Message-ID: <868ua1c0qu.fsf@stephe-leake.org> 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 X-Trace: ger.gmane.org 1437995634 20299 80.91.229.3 (27 Jul 2015 11:13:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 11:13:54 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 13:13:44 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 1ZJgLc-0003Ez-7N for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 13:13:32 +0200 Original-Received: from localhost ([::1]:52748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJgLb-0002t0-MZ for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 07:13:31 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43326) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJgLX-0002r6-6j for emacs-devel@gnu.org; Mon, 27 Jul 2015 07:13:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJgLT-00055E-Tj for emacs-devel@gnu.org; Mon, 27 Jul 2015 07:13:27 -0400 Original-Received: from gproxy9-pub.mail.unifiedlayer.com ([69.89.20.122]:45628) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZJgLT-000553-Mo for emacs-devel@gnu.org; Mon, 27 Jul 2015 07:13:23 -0400 Original-Received: (qmail 9017 invoked by uid 0); 27 Jul 2015 11:13:19 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 27 Jul 2015 11:13:19 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id xPDC1q00X2UdiVW01PDFDi; Mon, 27 Jul 2015 05:13:18 -0600 X-Authority-Analysis: v=2.1 cv=NJxGpSKg c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=y7kgw_RnJtkA:10 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=zOBTXjUuO1YA:10 a=P-ICsynqAAAA:8 a=yDXFvMq5UsP5i4taDH4A:9 Original-Received: from [76.218.37.33] (port=63077 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZJgLI-0008JE-Re for emacs-devel@gnu.org; Mon, 27 Jul 2015 05:13:13 -0600 In-Reply-To: (John Yates's message of "Sun, 26 Jul 2015 19:56:52 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.20.122 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:188106 Archived-At: John Yates 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