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 14:27:37 +0300 Message-ID: <55B615A9.5020907@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> <868ua1c0qu.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1437996489 2405 80.91.229.3 (27 Jul 2015 11:28:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 11:28:09 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 13:27:58 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 1ZJgZW-0007i3-80 for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 13:27:54 +0200 Original-Received: from localhost ([::1]:52792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJgZV-0002Pm-HV for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 07:27:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47397) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJgZS-0002Pd-0f for emacs-devel@gnu.org; Mon, 27 Jul 2015 07:27:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJgZL-0003oD-4I for emacs-devel@gnu.org; Mon, 27 Jul 2015 07:27:49 -0400 Original-Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:38245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJgZK-0003ni-S9 for emacs-devel@gnu.org; Mon, 27 Jul 2015 07:27:43 -0400 Original-Received: by wibxm9 with SMTP id xm9so111925476wib.1 for ; Mon, 27 Jul 2015 04:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=MxOwTejWaY7rjLmWB7Zo2IfwFT8i9S0vehUhWMWy6tg=; b=PfZMHl8adL4KvlyRXs7LrjHJkRIB/MpsOqkq9aa/QyWpMy12nMWRfk0pbhpceMS1AS uSvWefHEFsCiKLr/FkE8kiynVaPJ/gWCwmHW8d/tBRJXxlzcLZgXB7/ICkNsAetcYyt5 LxOyhRTP5kD6kGffv0a6uhPyiMrJQCWiDN5TSmNYHQbp/MgHXSe2HyB2WL9vs6D1PXem b4taVKpSM42PInfOwYCNyJed66NUhbCZR/03eUVpq+w24x2dXZ+Ih3dvW1fuTctVbTWc 6My0dygB5kepZjyy+yfhhRWj//7wEhuJxLuSOMTVIRZA//BYhJC45D/6Fntc6HNWZ9wB Jxpg== X-Received: by 10.180.23.33 with SMTP id j1mr21780435wif.44.1437996461311; Mon, 27 Jul 2015 04:27:41 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id m4sm27367526wjb.37.2015.07.27.04.27.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 04:27:40 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <868ua1c0qu.fsf@stephe-leake.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::229 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:188107 Archived-At: On 07/27/2015 02:12 PM, Stephen Leake wrote: > 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. I thought you were talking about caching the list of files, not their contents? The former won't help you with keeping xref-find-definitions working. The latter is a whole different (complex) discussion, largely unrelated to the project API. We've touched on it in the thread about hidden buffers. > On the other hand, the existing cache allows most xref commands to still > work. So you keep it for a while. You may be thinking of some cached data somewhere in the implementation of the xref backend. That's a valid approach, but neither the project API, nor xref API should know anything about it. It's an implementation detail. > 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. You can keep the xref buffer with the results of the last search, for a while, but as you continue editing files, those entries will also begin to point at wrong locations. The exact point at which they stop working will depend on the specific implementation of xref-location-marker, though. xref-etags-location is designed to be quite resilient, for instance.