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: Wed, 14 Oct 2015 08:05:15 -0400 Message-ID: <561E44FB.2030508@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> 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 1444824465 15423 80.91.229.3 (14 Oct 2015 12:07:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 12:07:45 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup , Eric Ludlam Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 14 14:07:40 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 1ZmKqK-0003OY-1x for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 14:07:40 +0200 Original-Received: from localhost ([::1]:42015 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmKqE-0003Cn-0N for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 08:07:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmKo4-0001xg-UZ for emacs-devel@gnu.org; Wed, 14 Oct 2015 08:05:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmKo1-0005BT-My for emacs-devel@gnu.org; Wed, 14 Oct 2015 08:05:20 -0400 Original-Received: from mail-qg0-x236.google.com ([2607:f8b0:400d:c04::236]:36321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmKo1-0005BK-Hz; Wed, 14 Oct 2015 08:05:17 -0400 Original-Received: by qgx61 with SMTP id 61so40008139qgx.3; Wed, 14 Oct 2015 05:05:17 -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=6OVBJC0i/JeWh5CejOceyB4Tzrflx2WJbvqyL2OgdiA=; b=aggy8z1IPnOCE0ZgzcyV5aU7nAzjaLqtR1OpnIJYmqgiaPrKs2ESf6gjkYqt5T7EtB XOdn2l/05a8FqYjTtRCn6OA+O/N1rK8MFUDKRQc6c2erWZhuEoo8RTUf4FI6UV9pmnR6 L6zGBz6VloMQJdjeUJ2Av03kgkWoVYZA24VBcAhc+5ode0lbNNqtKfaXhShqDJudP4tA NXpgPfpcHSrNgXyRK9KP3WlJOegZ+dLP4sTRZoqicdY42evL/gfmN4sj9KOv/suEofHH PmUJVUOhtZBMIEG78ictanCNkTzqrKNPHXo7Ue0n7A+apP1fzV2y6GQDUTA7rDtTo9tm 8gLg== X-Received: by 10.140.134.80 with SMTP id 77mr3477215qhg.103.1444824317083; Wed, 14 Oct 2015 05:05:17 -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 m100sm3212565qkh.42.2015.10.14.05.05.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2015 05:05:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: <87fv1d6fdf.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c04::236 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:191550 Archived-At: On 10/14/2015 04:09 AM, David Kastrup wrote: > Eric Ludlam writes: > >> On 10/13/2015 12:28 PM, David Kastrup wrote: >> Based on the many emails I've seen on the topic, I suspect the answer >> is: * It is hard to configure (ie - setting up project files, include >> paths, or whatever.) * Specific implementations are incomplete (ie - >> c++ || other parser is imperfect, the project system doesn't >> implement some feature, etc) * It is compared against better staffed >> tools > I got rid of it because it tended to eat all my CPU repeatedly digging > through buffers and files in the background. I don't want some tool to > go treasure-hunting for hours in my directories without concrete cause, > then restart for inscrutable reasons. > > It had its own idea of projects not matching the projects I was working > with, and it's an absolute no-go for Emacs to meddle with project > organization: I want to be able to jump in with Emacs into any project > without any pre- or post-configuration. Thanks for the diverse feedback. The need to move your files into some new structure is something I've always avoided. There is a "do it for you" project structure if you don't care, and several other types that just uses what you have, and can detect a bunch of variants without leaving its own files behind. > > Maybe that's a decisive difference between what people got to expect > from an IDE and I expect from Emacs: if someone develops stuff in Visual > C++, everybody in the project is expected to use the project > organization tools of the Visual C++ IDE. But I don't want my choice of > Emacs as an editor bleed all over a project. > > Now you'll say that EDE (or Semantic, or whatever other component) is > entirely optional but it's hard to figure out just what the relations of > the various parts of CEDET are. If you want to just work with the code > you have and not get stuff messed up, at some point of time it's easier > to just forego the whole inscrutable package and simplify one's life 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. AFAIK, every smart completion engine out there has the same dependency. There are plenty of others that don't, like Global which just finds what's there and makes the most of it, but it isn't smart completion. I suspect what you'd really like is to say "yeah, I'd like some smart completion with a side of API doc", and have an auto-configure thingy do the rest. Sounds great! To make that happen though, we need Emacs to be taught how to detect your files and rummage through them to make it happen. If you work on code of a style I or other contributors never worked on, it probably isn't in CEDET. Pulling in external tools like gcc, clang, whatever to do the work is a great way to make that happen as it pushes the CPU work off of Emacs' thread, and in some cases brings knowledge of the project along with it. Doing that type of integration can be done with CEDET's framework, or independent of it. I am not advocating to not do that type of integration, but to consider doing it in CEDET's framework because: a) it will be easier than starting from scratch b) doesn't preclude other types of integration later On 10/14/2015 06:47 AM, Dmitry Gutov wrote: > My already-stated impression is that it's over-specialized and tightly > coupled. > There are definitely dependencies. I don't think it is over-specialized, but perhaps overly-generalized. Every layer was set up so new languages, modes, projects, whatever can be slotted into the system. The tendency is that many are not complete which lends itself to disappointment. This is not uncommon in Emacs. There are lots of modes floating around with no indentation, poor syntax tables and incomplete highlighting. > Not saying that the problem domain is easy, but being able to use > different pieces of the solution separately would go a long way > towards alleviating the complaint that certain other parts are > incomplete. > I agree, this would be nice. > Especially if it were easier to swap in different solutions for some > of those parts (and do entirely without some others), and do that in > not too many lines, all as part of the user's configuration. It is possible to swap in different solutions (under the CEDET framework) but in many cases, there is currently only one solution. In these conversations it is hard to distinguish if the (usually valid) criticism are about CEDET the framework, or about various implementations under CEDET. It is also hard since I don't really have time to address the issues raised. Eric