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: running EDE from a file that is not under a project root dir Date: Thu, 06 Aug 2015 03:37:29 -0500 Message-ID: <8637zwbynq.fsf@stephe-leake.org> References: <861tfiexaz.fsf@stephe-leake.org> <55C16D73.6080801@siege-engine.com> <86egjick23.fsf@stephe-leake.org> <55C1F6A8.8030901@siege-engine.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438850285 22828 80.91.229.3 (6 Aug 2015 08:38:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 08:38:05 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 06 10:37: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 1ZNGgR-0001oe-Li for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 10:37:51 +0200 Original-Received: from localhost ([::1]:43929 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNGgR-0001hQ-4R for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 04:37:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36333) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNGgN-0001hH-Iw for emacs-devel@gnu.org; Thu, 06 Aug 2015 04:37:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNGgI-0000PF-Bx for emacs-devel@gnu.org; Thu, 06 Aug 2015 04:37:47 -0400 Original-Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]:59106) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZNGgI-0000Ot-4o for emacs-devel@gnu.org; Thu, 06 Aug 2015 04:37:42 -0400 Original-Received: (qmail 30501 invoked by uid 0); 6 Aug 2015 08:37:40 -0000 Original-Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 6 Aug 2015 08:37:40 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw4 with id 1Ldd1r0012UdiVW01Ldg9q; Thu, 06 Aug 2015 02:37:40 -0600 X-Authority-Analysis: v=2.1 cv=OJm0g0qB 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=dMuJOXMfAAAA:8 a=RS0KL2qjvv5B1EGgWHkA:9 Original-Received: from [76.218.37.33] (port=50405 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZNGgC-0000JC-Qt for emacs-devel@gnu.org; Thu, 06 Aug 2015 02:37:36 -0600 In-Reply-To: <55C1F6A8.8030901@siege-engine.com> (Eric Ludlam's message of "Wed, 05 Aug 2015 07:42:32 -0400") 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: 69.89.23.142 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:188482 Archived-At: Eric Ludlam writes: > On 08/05/2015 02:43 AM, Stephen Leake wrote: >>> >I find the global project concept scary. I can't say how many times >>> >I've edited Emacs code that was wasn't on my load path because I had >>> >multiple checkouts of the same code. Mostly just too many times. >> You misunderstand my point. I don't want a project that includes all >> files on the disk (which is what I think you are refering to); I want a >> single project that is active in all buffers. >> >> Most other IDEs I've used have the notion of a single active project; >> the splash screen asks for the project to open. >> >> That's how Emacs Ada mode works; the user selects the single active >> project. They can later select another one. > > I have used IDEs with "global" projects, and I consider Emacs an IDE > with a single global project for "emacs lisp" code (among other > things, of course. :) It has handy functions like 'find-function' and > 'find-library' that lets you move to definitions and files. I use Emacs as an IDE for all kinds of things, not just elisp. I assume you do as well; that's what EDE does, after all. > The reason I don't like global projects is that if you are in one > resource (for Emacs any old .el, .txt, etc) and call `find-function', > it will jump off to the code, but unless you pay attention, you might > end up somewhere you don't expect. For example, if I have two > versions of my source code open, such as ede.el in Emacs vs ede.el in > CEDET's repository, and I blindly jump from a symbol, I'll could end > up in the wrong place based on what my load path is. I find that an odd definition of "wrong". Since you know 'find-function' searches load-path, why would you expect to go somewhere that is not on load-path? I guess you mean something like "I forget to change load-path when I switch to thinking about a different project". That makes sense; Emacs does not provide a menu for a set of load-path settings. That's one thing an elisp project backend should do; similar to setting the source file path for a gcc project. There should be a menu of possible projects to choose from, so it becomes easy to change load-path. Of course, since Emacs doesn't support unloading things, you can't take this very far; at some point, you have to quit and restart Emacs. But then the menu can still be there to choose what project to work on. > In my mind, all files should be deterministically bound to a project > so when you perform an operation, you always know where you're going. Many files are in core sub-projects that reused in higher-level projects; most Emacs code uses window.el and other core files, some Emacs code uses ELPA libraries; all C code uses the C standard library, some C code uses many other libraries. So I don't see how you can definitively determine the search path from looking at a single file. In addition, just because I'm in an Ada file doesn't mean I want to search for other Ada files; sometimes I do, sometimes I don't. That's _exactly_ why I prefer a single globally active project that I explicitly select; then I know what the search path is, no matter what file I'm in. And when I decide to start thinking about a different project, I tell Emacs that by selecting that project from the menu. Then Emacs _knows_ what I'm thinking about; it doesn't have to guess. > Some files are "in" projects. In your case, a way to associate a notes > file outside a project to a project sounds important. > > Having a 'global' project could be useful if you only ever edit one > project at a time in a given emacs instance, Yes. > and you want everything > to behave as if it were. Were what? If you mean "Emacs should treat all files on the disk as if they were part of the current project", then no. For example, if you are in an Ada file that is not part of the current project, and invoke 'ada-find-other-file' (to move from body to specification), you will get an error "file is not in the current project". That prevents the sort of error you describe above. But all commands that use project information should get it from the single current project, yes. > I don't picture most Emacs users operating > like that. I have no idea who "most Emacs users" are, or how they use it. I do know a few users, and they use it like I do (mostly because I taught them :). I have heard complaints that "emacs is not like other IDEs". So when I see _every_ other IDE providing a single global project, it seems obvious that Emacs should support that as well. > If it is feature to be added, it should be optional. Of course; that is the Emacs Prime Directive :). There are two levels of "optional" here; `ede-current-project' could always check the global var first; people who don't want that style just leave it set to nil. Or the single global variable could be one of a user-configurable list of things that ede-current-project checks. I haven't read the ede code carefully enough yet to say which might be better. Hmm. In addition, I would expect the Development | Load Project menu command to set the global variable, but others won't. So that needs to be configurable somehow. Ah; if ede-current-project is set to not check the global variable, it doesn't matter if it gets set. That was easy :). -- -- Stephe