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: progmodes/project.el and search paths Date: Sun, 09 Aug 2015 00:18:33 -0500 Message-ID: <86si7t11li.fsf@stephe-leake.org> References: <55BE209F.1000009@siege-engine.com> <55BE509B.2080307@yandex.ru> <55BEC1B5.6060204@gmail.com> <86twsgfiuc.fsf@stephe-leake.org> <87mvy2kjxa.fsf@esperi.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439097558 7220 80.91.229.3 (9 Aug 2015 05:19:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 05:19:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 07:19:07 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 1ZOJ0j-0002FY-Uj for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 07:19:06 +0200 Original-Received: from localhost ([::1]:54402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOJ0j-0005fS-6B for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 01:19:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOJ0X-0005f8-38 for emacs-devel@gnu.org; Sun, 09 Aug 2015 01:18:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOJ0T-0007mJ-Kv for emacs-devel@gnu.org; Sun, 09 Aug 2015 01:18:53 -0400 Original-Received: from gproxy7-pub.mail.unifiedlayer.com ([70.40.196.235]:59671) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZOJ0T-0007jj-Dv for emacs-devel@gnu.org; Sun, 09 Aug 2015 01:18:49 -0400 Original-Received: (qmail 4885 invoked by uid 0); 9 Aug 2015 05:18:43 -0000 Original-Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy7.mail.unifiedlayer.com with SMTP; 9 Aug 2015 05:18:43 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by CMOut01 with id 2VJe1r0032UdiVW01VJhXk; Sat, 08 Aug 2015 23:18:43 -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=uRRa74qj2VoA:10 a=vbyJIY8eAAAA:8 a=i4mH3sMsId7QaLz4YZ0A:9 Original-Received: from [76.218.37.33] (port=65261 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZOJ0I-0000d6-DB for emacs-devel@gnu.org; Sat, 08 Aug 2015 23:18:38 -0600 In-Reply-To: <87mvy2kjxa.fsf@esperi.org.uk> (nix@esperi.org.uk's message of "Sat, 08 Aug 2015 14:07:45 +0100") 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: 70.40.196.235 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:188630 Archived-At: Nix writes: > On 3 Aug 2015, Stephen Leake told this: >> I prefer to cache it in a global variable; that way, I have only one >> project active at a time, for all buffers. > > That doesn't work very well for those of us working on multi-component > projects. Fine; of course this behavior should be user-configurable. At the same time, I work on multi-component projects all the time, and one active project works for me. > If I'm working in the Linux kernel I do *not* want identifier > search or file lookup wandering into glibc or Emacs, even though they > share some identifiers (with completely divergent definitions) and even > though I may have quite a lot of buffers open on those projects. > (I have fairly often worked on things that affect glibc, binutils, GCC, > and the kernel all at once. Those are different projects with distinct > roots, identifier sets, and tags tables...) But if you are in glibc, looking at an identifier for a function that happens to be defined in the linux kernel, you want to be able to find the corresponding definition; the linux kernel is a subproject of glibc (which is a subproject of higher level projects like Emacs). So the Emacs project tools should reflect that. For example, file name completion must handle duplicate file names. That's a problem right now in Emacs for elisp files; there are both lisp/cedet/ede/dired.el and lisp/dired.el in Emacs core. 'load' and 'require' handle this by having only lisp/cedet in load-path, not lisp/cedet/ede. So if I do file name completion with just load-path, I have to know to type ede/d when searching for ede/dired.el, which is _not_ friendly. But if I do file name completion with an expanded load path that includes cedet/ede, it shows only one dired.el (it happens to be ede/dired.el). Which is also not friendly; I'll be filing a bug report on this later today. For identifier search, you can use a cross reference tool that understands name overloading; AdaCore asistant is one - it uses cross reference information output by the compiler, which obviously handles the duplicate names correctly. The multi-component projects I work on are in Ada, using the AdaCore tools. Both make multi-component projects easier to work with, and Emacs Ada mode understands the full project structure. Recently we added a large C++ component to one product, and it suffered from some of the above problems. So part of the solution is using a better programming language (not always a choice, but it will never happen if we don't ask for it!). In addition, sometimes the user wants to search all subprojects, sometimes a subset. So we need a good way of specifying subsets of subprojects at search time. Emacs Ada mode doesn't support this yet (I just put up with the unwanted hits in searches; better than false negaitives). Hardcoding the searchable subset to only the top-level project is overly restrictive. -- -- Stephe