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: progmodes/project.el and search paths Date: Tue, 4 Aug 2015 19:09:01 +0300 Message-ID: <55C0E39D.4050601@yandex.ru> References: <55BE209F.1000009@siege-engine.com> <55BE509B.2080307@yandex.ru> <55BEC1B5.6060204@gmail.com> <55BFEF66.1090505@yandex.ru> <55C0A777.1030101@gmail.com> 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 1438704945 32083 80.91.229.3 (4 Aug 2015 16:15:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Aug 2015 16:15:45 +0000 (UTC) To: Eric Ludlam , Emacs Development Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 04 18:15: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 1ZMesP-0006Q8-Fe for ged-emacs-devel@m.gmane.org; Tue, 04 Aug 2015 18:15:41 +0200 Original-Received: from localhost ([::1]:36240 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMesO-00009k-Cm for ged-emacs-devel@m.gmane.org; Tue, 04 Aug 2015 12:15:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36231) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMemB-0000lw-I1 for emacs-devel@gnu.org; Tue, 04 Aug 2015 12:09:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMem2-0002VL-4v for emacs-devel@gnu.org; Tue, 04 Aug 2015 12:09:15 -0400 Original-Received: from mail-lb0-x236.google.com ([2a00:1450:4010:c04::236]:33745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMem1-0002V7-TN for emacs-devel@gnu.org; Tue, 04 Aug 2015 12:09:06 -0400 Original-Received: by lbbyj8 with SMTP id yj8so8970725lbb.0 for ; Tue, 04 Aug 2015 09:09:04 -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=HIFvliKObJ9yJ2mWVOr59fi7vIoidQFyrz4tB1oTY+8=; b=wxIT97XXX4ARfTHhxJXm2lYzpSliL9fIBsuf0C1nnkc5cyE8kw2k5LgUMi4E0TmR+i d5QJVwGKbNivok1DyGrqDQ1wKHH9dCsJ9gvCl81RRNyErp8oi9RMid1NcW+4eInvh/rc UL02W9aKA22DViCczLzGNNxnIi1JnikJXo5HlzUD4X39nY7MczKVQoHt21rZnN442jsL I18ls6TfltgB4Hex8TlCIewKWvJh5fuck29fcJvhtTuTgMGAUuWvbiN422MoEvbC9z02 3YA2nOuLGdj6ftEhmSyyt1rfeNuKJa6Xn8BNcnR575CxJH+JtdCFyLdtk6es+HXWD9J+ 1KXg== X-Received: by 10.112.157.36 with SMTP id wj4mr4349763lbb.115.1438704544145; Tue, 04 Aug 2015 09:09:04 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id su8sm306827lbc.41.2015.08.04.09.09.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Aug 2015 09:09:03 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: <55C0A777.1030101@gmail.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::236 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:188398 Archived-At: On 08/04/2015 02:52 PM, Eric Ludlam wrote: > That is true now for project.el. Once you support 20+ project > definitions as in EDE where vc is just one of them, all that negligible > time adds up. I honestly expect that project-find-functions, for each individual user, will almost never reach even 10 items, let alone 20. > Asking all 20+ project definitions to do their own caching is something > EDE used to do, and it was a pain to maintain. I recommend against it. You were able to do caching thanks to allowing some restrictions on how the current project depends on the current buffer (basically, along the lines of locate-dominating-file). Just a day or two ago, Stephen Leake posted that he was writing a project implementation that's active everywhere, as soon as the user visits the project. Caching is probably still possible, even in view of that, but there are more things to consider.