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 16:00:03 +0300 Message-ID: <55B62B53.5060003@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=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1438002021 27564 80.91.229.3 (27 Jul 2015 13:00:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2015 13:00:21 +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 15:00:21 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 1ZJi0u-0007HZ-Pb for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 15:00:16 +0200 Original-Received: from localhost ([::1]:53312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJi0u-0002wX-6L for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2015 09:00:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46462) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJi0o-0002wJ-Gq for emacs-devel@gnu.org; Mon, 27 Jul 2015 09:00:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJi0l-00067f-QP for emacs-devel@gnu.org; Mon, 27 Jul 2015 09:00:10 -0400 Original-Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:33373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJi0l-00066V-IU for emacs-devel@gnu.org; Mon, 27 Jul 2015 09:00:07 -0400 Original-Received: by wicmv11 with SMTP id mv11so138322985wic.0 for ; Mon, 27 Jul 2015 06:00:06 -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=uvw2neA0OtmU57Nk4lCW4/5gpX6yCGOMuvOJZaddTj8=; b=EWWg6IuFFXbM7ijoNlbB5NYQYterzgkyEngVwyzJIErqPdXhE48mMNbr6bQEGSGCQG A5qrXSFwi0zlJJBYh7qDTVu1Kfh8AChM/8Tmxbh6tXBu0pgqJ32K73XvxKdU939Tdq7u Voz4mu9fNSvA1q9Y+OqZ/mEgytae27VCd45+lDWyYvZ4XEPTWmp0LKdkj11yt4QGxQi9 ZktPI3gdLEllMgPy7b0+hfA+ie3ccIGTYDymnohYSEMlPIgfg1JeXzSUPza93jTpUr4X /9VAzTyh81P0+l8+/oBSII0dQtTra8rQkVwgzwqqy2cB0IQm0fLnSOTT3n0U55Ro3X+R b5qQ== X-Received: by 10.180.37.200 with SMTP id a8mr22871930wik.26.1438002006508; Mon, 27 Jul 2015 06:00:06 -0700 (PDT) Original-Received: from [10.9.0.103] (nat.webazilla.com. [78.140.128.228]) by smtp.googlemail.com with ESMTPSA id r19sm13558798wib.7.2015.07.27.06.00.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2015 06:00:05 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: <86oaiybvbf.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::231 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:188108 Archived-At: On 07/26/2015 09:57 PM, Stephen Leake wrote: > Then it's not "global", is it? It's "operate on this set of projects, > exclude that set". So you need a way to specify sets of projects. Maybe the "global" is not the right word, but I'm quite confident that if I ask an average user what a "search across project" action should do, it would replace in the current project, (maybe) in the included ones, and definitely not in the installed libraries. Even if they're writable. Even if we add a "choose which projects to touch" interface, it's good to have a reasonable default. >> But according to you, the "search path" will be just the directories >> inside the project's tree, right? > > No, I have been explicitly saying that is not the case; the search path > is whatever the project file says it is. Sorry, I've replied to that part before reading the rest, and then forgot about it. > A list of project names. Depending on the project manager, that implies > a list of project files in one syntax or another, each of which > specifies a set of project directories (explicitly or implicitly). Could you give an example? Since they're referred only by names, this sounds like a list of dependencies on the installed packages. Those we usually don't want to edit, and I'd classify them as system includes. > Trust what the project file says. The user told Emacs to use the project > file; it should not try to be smarter. So, xref-find-regexp won't call project-root. Got it. > If the user wants documentation in the project, then it is in the > project file. If the project manager tool is brain-dead and can't handle > documentation, the the user can switch tools. In that case, will the user add the documentation directory to the search-path section of the project file? > No. We should have project-root for tools that need a root directory. > xref-find-regexp needs a search path, not a root directory. It could include the root directory in the search path, if it's not already there. But it seems you don't want to do that. Okay. > xref-find-regexp searches project-search-path. project-search-path is > set by reading the project files. The project files are provided by the > user. Voila, xref-find-regexp does _exactly_ what the user wants, no > more, no less. Very well. To sum up, I see a strong case for project-search-path as you described it (maybe under a different name; like project-directories, as it is now), and so far, no real case for project-root. Further, the system search path should be separate, because it's usually specified like that in project files already, in my experience. And if someone were to create, say, an ECB panel showing the current project layout, they might appreciate having the information about these directories being different. If you (or someone else) don't like using "project search path" for the system libraries path, feel free to suggest another name.