From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nix Newsgroups: gmane.emacs.devel Subject: Re: progmodes/project.el and search paths Date: Mon, 10 Aug 2015 18:12:43 +0100 Message-ID: <87y4hjrrsk.fsf@esperi.org.uk> References: <55BE209F.1000009@siege-engine.com> <55BE509B.2080307@yandex.ru> <55BEC1B5.6060204@gmail.com> <86twsgfiuc.fsf@stephe-leake.org> <87mvy2kjxa.fsf@esperi.org.uk> <86si7t11li.fsf@stephe-leake.org> <87lhdkzmdv.fsf@isaac.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439226840 12969 80.91.229.3 (10 Aug 2015 17:14:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Aug 2015 17:14:00 +0000 (UTC) Cc: Stephen Leake , emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 10 19:13: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 1ZOqdv-0001CJ-Qr for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 19:13:48 +0200 Original-Received: from localhost ([::1]:59524 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOqdv-0005qE-33 for ged-emacs-devel@m.gmane.org; Mon, 10 Aug 2015 13:13:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOqd2-0004n6-Mf for emacs-devel@gnu.org; Mon, 10 Aug 2015 13:12:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOqcx-0004Ap-4X for emacs-devel@gnu.org; Mon, 10 Aug 2015 13:12:52 -0400 Original-Received: from icebox.esperi.org.uk ([81.187.191.129]:49708 helo=mail.esperi.org.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOqcw-0004AN-Tj for emacs-devel@gnu.org; Mon, 10 Aug 2015 13:12:47 -0400 Original-Received: from spindle (nix@spindle.srvr.nix [192.168.14.15]) by mail.esperi.org.uk (8.15.2/8.15.2) with ESMTP id t7AHChoB016220; Mon, 10 Aug 2015 18:12:43 +0100 Emacs: the definitive fritterware. In-Reply-To: <87lhdkzmdv.fsf@isaac.fritz.box> (David Engster's message of "Sun, 09 Aug 2015 14:17:48 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DCC-URT-Metrics: spindle 1060; Body=3 Fuz1=3 Fuz2=3 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 81.187.191.129 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:188693 Archived-At: On 9 Aug 2015, David Engster outgrape: > Stephen Leake writes: >> 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). > > I must say I find this to be a very unusual view. In this specific case, I'd call it strictly incorrect. I picked those examples for a reason: they're an example of two sorta-related projects which define identical identifiers which relate to *different things* in each project: the kernel is in effect a freestanding environment and *does not* depend on glibc (indeed, the opposite is true, glibc depends on the kernel, even though it cannot resolve any symbols in it and no identifier lookups should ever traverse from the one to the other). e.g. the kernel defines many of the *printf() functions, and so does glibc -- but they define them in different places. If something inside glibc references snprintf(), the identifier lookup should proceed within glibc alone: if something inside the kernel references snprintf(), it had better find the copy in the kernel's lib/vsprintf.c. (Meanwhile, there are a lot of projects that really *do* depend on each other and symbol resolution in one can look up symbols in the other: it would be nice if identifier search could follow that, but it is very far from crucial.) >> 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. > > This is a different problem. You are within one project here; of course > a project system should be able to handle this. Yes indeed. -- NULL && (void)