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: project.el semantics Date: Fri, 18 Sep 2015 11:08:01 -0500 Message-ID: <86twqrww0u.fsf_-_@stephe-leake.org> References: <86pp1j4ejm.fsf@stephe-leake.org> <55F899EA.7050700@yandex.ru> <86lhc73wog.fsf@stephe-leake.org> <86mvwn11u1.fsf@stephe-leake.org> <55F8E451.9080902@yandex.ru> <86bnd21q0r.fsf@stephe-leake.org> <55F97EA2.9000408@yandex.ru> <86mvwmz58h.fsf@stephe-leake.org> <55F9A5F8.1030505@yandex.ru> <86pp1ixem2.fsf@stephe-leake.org> <55FAFC36.5010506@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442592543 23263 80.91.229.3 (18 Sep 2015 16:09:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 18 Sep 2015 16:09:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 18 18:08:52 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 1ZcyDT-0000HD-Ni for ged-emacs-devel@m.gmane.org; Fri, 18 Sep 2015 18:08:51 +0200 Original-Received: from localhost ([::1]:40254 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcyDT-0007fW-Bl for ged-emacs-devel@m.gmane.org; Fri, 18 Sep 2015 12:08:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41447) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcyDI-0007fO-9E for emacs-devel@gnu.org; Fri, 18 Sep 2015 12:08:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcyDD-0002ra-6z for emacs-devel@gnu.org; Fri, 18 Sep 2015 12:08:40 -0400 Original-Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]:59961) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZcyDD-0002nA-0J for emacs-devel@gnu.org; Fri, 18 Sep 2015 12:08:35 -0400 Original-Received: (qmail 16137 invoked by uid 0); 18 Sep 2015 16:08:26 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 18 Sep 2015 16:08:26 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id Jg8G1r00N2UdiVW01g8KAg; Fri, 18 Sep 2015 10:08:25 -0600 X-Authority-Analysis: v=2.1 cv=EbVbHpWC 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=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=ff-B7xzCdYMA:10 a=vaJtXVxTAAAA:8 a=gx7TJZa0Odjccz3LHiMA:9 Original-Received: from [76.218.37.33] (port=64753 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZcyCs-0008Ck-No for emacs-devel@gnu.org; Fri, 18 Sep 2015 10:08:16 -0600 In-Reply-To: <55FAFC36.5010506@yandex.ru> (Dmitry Gutov's message of "Thu, 17 Sep 2015 20:45:26 +0300") 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: 67.222.33.93 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:190057 Archived-At: Dmitry Gutov writes: > On 09/17/2015 12:01 AM, Stephen Leake wrote: > >> Does this mean file name completion should search on project-roots, not >> project-search-path, for this use case? > > Err, that looks like a non-sequitur to me. project-find-file should > search in where it's defined to search (up to you). It just occurs to > me that some users might expect it to only list files in the currently > opened project(s), whereas other users would like to jump to system > include files as well. > >> xref-find-regexp searches on both, which is redundant. For example, for >> a file in Emacs core, using only project-try-vc in project-find-files, >> project-roots returns ("c:/Projects/emacs/master/"), and >> project-search-path includes that directory along with others. > > It's kinda redundant, but as long we define project-search-path as a > list of directories with *source* files, it may omit the root > directories if they contain only, say, documentation. But we want > xref-find-regexp to search in documentation as well. Both find-file-in-project and xref-find-regexp are client code using the project API. In order to use the API correctly, the semantics of each call must be well-defined. That means it must be possible to tell from the API as defined by project.el (and some future project.texi) what functions to call for these two uses. They cannot rely on vague guesses about what some backend might do, or what the user might want. That means project-search-path should be clearly defined to be either purely recursive or not, so client code and project backends know whether to weed out duplicates or not. It also means the distinction between project-search-path and project-roots must be more clearly defined. If there are use cases where different search paths are desired for different purposes (such as "source" vs "documentation" above), the the project API must provide a clear mechanism to distinguish those cases, so the appropriate search path can be returned. The current doc strings for project-search-path and project-roots do not make that clear, and the way they are used and implemented in current code makes project-roots purely redundant (no code would be harmed by simply deleting it, and some would be improved thru reduced redundancy). -- -- Stephe