From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: progmodes/project.el and search paths Date: Sun, 09 Aug 2015 14:17:48 +0200 Message-ID: <87lhdkzmdv.fsf@isaac.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439122702 20472 80.91.229.3 (9 Aug 2015 12:18:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 12:18:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 14:18:13 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 1ZOPYJ-0006lR-5y for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 14:18:11 +0200 Original-Received: from localhost ([::1]:55152 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOPYI-00043z-66 for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 08:18:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35570) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOPYE-00040g-Ax for emacs-devel@gnu.org; Sun, 09 Aug 2015 08:18:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOPYA-0000Nk-AT for emacs-devel@gnu.org; Sun, 09 Aug 2015 08:18:06 -0400 Original-Received: from randomsample.de ([5.45.97.173]:38691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOPYA-0000LN-1L for emacs-devel@gnu.org; Sun, 09 Aug 2015 08:18:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=DwisUV6aW8uULnu8nv+sekzoW3GM1nTmDvhXs6sLhjk=; b=iDiLNJD9UQ7ZpXS31B7/kuOAyAaB3DraMM6dSOL7A/OOJnuJ3j+MDEgaPVxt3fF6QN61pt72ueM05IkWhO1FhAxZV9gYKdIwlyXCpffc85DO4ICsb74L0qu/hwoQ6y6J; Original-Received: from ip4d145d5e.dynamic.kabel-deutschland.de ([77.20.93.94] helo=isaac.fritz.box) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ZOPY2-0005os-OZ; Sun, 09 Aug 2015 14:17:54 +0200 In-Reply-To: <86si7t11li.fsf@stephe-leake.org> (Stephen Leake's message of "Sun, 09 Aug 2015 00:18:33 -0500") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.4 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 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:188636 Archived-At: 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. Just because a program depends on libc, the libc is not a "subproject". Instead, you have a dependency on a library which has a fixed API. The only thing you need are the declarations of the API and the needed type definitions, which are given through the system headers, but those hardly qualify as a "subproject"; they simply state how libc functions must be called. I don't care how printf is implemented; in fact, I might have to switch to musl or ulibc if my target system can't handle glibc's size. You can of course have the full glibc and Emacs sources loaded as projects at the same time, but they are separate projects on the same level in the project hierarchy. > 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. -David