From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Ludlam Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Thu, 15 Oct 2015 09:08:23 -0400 Message-ID: <561FA547.5030901@gmail.com> References: <83fv1r3gzp.fsf@gnu.org> <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> <5612E996.7090700@yandex.ru> <83bnc7tavr.fsf@gnu.org> <5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org> <871tcyexa9.fsf@fimbulvetr.bsc.es> <87612a7my2.fsf@fencepost.gnu.org> <561DC925.5050001@siege-engine.com> <87fv1d6fdf.fsf@fencepost.gnu.org> <561E44FB.2030508@gmail.com> <561F2049.1030700@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1444914632 16901 80.91.229.3 (15 Oct 2015 13:10:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Oct 2015 13:10:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov , David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 15 15:10:32 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 1ZmiIf-00009M-KP for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 15:10:29 +0200 Original-Received: from localhost ([::1]:47431 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmiIf-00061x-9e for ged-emacs-devel@m.gmane.org; Thu, 15 Oct 2015 09:10:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmiGk-0004eu-Me for emacs-devel@gnu.org; Thu, 15 Oct 2015 09:08:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmiGf-0000XG-KQ for emacs-devel@gnu.org; Thu, 15 Oct 2015 09:08:30 -0400 Original-Received: from mail-qg0-x22c.google.com ([2607:f8b0:400d:c04::22c]:33480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmiGf-0000X0-Ey; Thu, 15 Oct 2015 09:08:25 -0400 Original-Received: by qgeo38 with SMTP id o38so25952527qge.0; Thu, 15 Oct 2015 06:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=VmghwSBtNeyPCa/S3rviZsnjtp4wo/SjAfIhExHpiL4=; b=zYhqbTAWHjWQwIaVxMcLhGZqwf6dL4Lcz5uP5Ms6SnUksnsqVV+sSz1Op903PLjKhM UntW7hO1EDiSoiGnEjLHd/XCsFmdWwtL8s6Fk37RZNiCrxg3ueMPrfNWw0wRN68WF7Bj BoslqC7oOEALpQpMvjTFEYY61bhdk+sWxE78qzzvfLOm+LSZxkmlYHMDiO5QO6TDHGsv dtwzno9Uh+BcvKiquuG1ujLqPMlR6/J87+KE8IJfQHCuv9Mc76b07ODwb/fatng17zfv m33DqaTNNowvPTOX5IS8L7RhcJ3ptqHVmEqWbktxGfAi5Jt/pgl5cAWnuXKsfpTHSXA3 CJ7w== X-Received: by 10.140.92.84 with SMTP id a78mr11602211qge.105.1444914504741; Thu, 15 Oct 2015 06:08:24 -0700 (PDT) Original-Received: from [192.168.1.202] (pool-71-184-198-118.bstnma.fios.verizon.net. [71.184.198.118]) by smtp.googlemail.com with ESMTPSA id x19sm5422112qkx.32.2015.10.15.06.08.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Oct 2015 06:08:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <561F2049.1030700@yandex.ru> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::22c 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:191636 Archived-At: On 10/14/2015 11:40 PM, Dmitry Gutov wrote: > On 10/14/2015 03:05 PM, Eric Ludlam wrote: > >> The puzzle for me here is that while the different pieces are >> technically independent, the more complex tasks, such as completion, >> depend on the other tools doing their job. Good smart completion >> depends on a knowledge of a project's structure to find headers (C/C++), >> and it also depends on rummaging around in your files to find the needed >> symbols. > > It seems what we need is a set of "juncture points", which define how > separate systems/tools should communicate. That's what xref and > project.el are about, for finding locations and project information > respectively; everything else in there is mostly for convenience. Indeed. That is a similarity. >> There are definitely dependencies. I don't think it is >> over-specialized, but perhaps overly-generalized. > > Could be both. But by over-specialized, I mean that a lot of stuff in > e.g. ede-project doesn't make sense for many projects. targets, for > example. And mailinglist/web-site-url/ftp-site?.. > There is indeed a bunch of extra not so useful things for all classes in the baseclasses. I would not claim it could not be improved. Some, such as 'version' and 'name' seem trivial, but become more convenient when you start browsing through your open projects. > I'm also under impression that EDE projects are always one directory > deep (and for each subdirectory, you need subprojects). Which reflects > the common Makefile usage, but not how projects are structured under > many other build systems. > Different projects handle this differently. The original set regarding both Automake and Makefile based projects are as you describe. Last year I simplified a bunch of systems regarding project detection and directory hierarchy. At this point, the 'simplest' project as far as setup is the 'generic' project type, one of which finds a project based on your VC root (git, cvs, and a few others). It is one project covering all the subdirectories. You can 'customize' the project and just fill in the blanks for your build system, include-path and others, or just ignore it all. >> It is possible to swap in different solutions (under the CEDET >> framework) but in many cases, there is currently only one solution. > > Yet still, to even become pluggable, a piece of functionality has to > buy into the CEDET fundamentals, like using EIEIO, mode-locals, and > CEDET's base classes. > Yes. The structure I started building used traditional emacsy tools for handling structure and buffer local behaviours. The broader the tool became, the more of a PITA it was managing all the random lists of behaviour differences, and random list references, so I put in missing infrastructure. You will note other tools that wrangle data now use defstruct (now part of emacs) or seem to create their own data structure with their own accessors, so building such tools is not unusual. I just tried to make mine more generally useful. Eric