From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sun, 18 Oct 2015 23:42:20 +0300 Message-ID: <5624042C.9000401@yandex.ru> References: <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> <561E32D2.4060501@yandex.ru> <83wpum3ozk.fsf@gnu.org> <87si59ln6u.fsf@isaac.fritz.box> <56224B63.3010803@yandex.ru> <87k2qlldny.fsf@isaac.fritz.box> <5622AD4D.3010504@yandex.ru> <87bnbwl7ac.fsf@isaac.fritz.box> <5623CA16.5090300@yandex.ru> <87wpukje2o.fsf@isaac.fritz.box> 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 1445200972 28252 80.91.229.3 (18 Oct 2015 20:42:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2015 20:42:52 +0000 (UTC) Cc: John Wiegley , Eli Zaretskii , emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 18 22:42:44 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 1Znumw-00028f-22 for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 22:42:42 +0200 Original-Received: from localhost ([::1]:35493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Znumv-0000XF-3A for ged-emacs-devel@m.gmane.org; Sun, 18 Oct 2015 16:42:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Znumi-0000X5-4i for emacs-devel@gnu.org; Sun, 18 Oct 2015 16:42:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Znume-0005fa-MF for emacs-devel@gnu.org; Sun, 18 Oct 2015 16:42:28 -0400 Original-Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:36943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Znume-0005fT-Dm; Sun, 18 Oct 2015 16:42:24 -0400 Original-Received: by wicfv8 with SMTP id fv8so52186537wic.0; Sun, 18 Oct 2015 13:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=kygWhHIfHMuxHdQRtRq1b7TPuCSFgDEjnxxAXTslsA8=; b=kwtFPXBUMmNFez6DZ24lM29T8n9lZWPXAgjrEZ3B65REQV2bRf/zMo+6n4IFRMnuey bp43DzaOQEE1QchExZFzQ4Cyn3dJiRFJdyTB7SnvfZZ/Rw8JRd6SmRZKSn8y4mR8VBp+ u+2Jr3EB9yl3TgmCvCGkHZ2kF9qcjYdBvLHSzhefQbR5Zd6wYOA9Af25J+RZmh6ZHF0a lNbLpQl0roh7lod/GelOEurXHUHmO39fqgZA4AVvMuUISQ/gcsmjWqmLJMTJL97nnqvV wXrlQ787NIUDnHAlMhDYRiYUeyat9bt4Ssel3Rr+6Dqheap4EtrPugUm9HRWe2vHeC1j MeUA== X-Received: by 10.180.99.8 with SMTP id em8mr16059530wib.8.1445200943788; Sun, 18 Oct 2015 13:42:23 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id gl9sm16423525wjb.10.2015.10.18.13.42.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Oct 2015 13:42:22 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: <87wpukje2o.fsf@isaac.fritz.box> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::229 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:192013 Archived-At: On 10/18/2015 08:12 PM, David Engster wrote: > http://www.jetbrains.org/intellij/sdk/docs/reference_guide/custom_language_support.html Thanks a lot, that should be very helpful. I have their Community Edition installed and try it out from time to time, but I haven't looked into their documentation, and this looks pretty good. > We don't. Makefiles are way too complex. The best solution IMHO is using > compilation databases, and EDE upstream has support for them. Of course, > it's another LLVM thingy, so I'm not sure if I'm allowed to merge it. I really think we should move CEDET to ELPA. It can allow you to keep the users up-to-date more easily, and would make cedet-devel-load.el unnecessary. The standard of what we're "allowed" to distribute, is also a bit more lax there, in practice. But if it turns out to be a problem, as long as the compilation database is pluggable, you could extract it into a new package and let users install it from MELPA, until the policy here gets with the times. > My point is that people say they want an Emacs to be an "IDE", but at > the same time they don't want to be restricted in their Emacs usage, and > rightfully so. A typical IDE like Visual C++ forces you into using their > project system, otherwise nothing will work. So people want > IDE-features, but at the same time they want all the freedom Emacs > allows. And that's what CEDET tries to support. Yes. The "project system" I'd expect from Emacs is pretty different. A lot of users have lived with a "lightweight" one (Projectile) for years, so I try to approach the subject in project.el also from that direction. > Eric started with EDE as a project system similar to other IDEs, that > means you can start a project from scratch with EDE and it will manage > the build for you by generating a Makefile. While technically > impressive, I never liked this kind of project system, and honestly, I > think we should probably drop that part from EDE. I'd say drop it, but you might have users depending on it. > But you are not forced > to use it, because Eric also added a custom project detection that is > very flexible. But if you manage the build yourself, you have to specify > everything manually (include paths, used compiler, etc.). But you can also create a specialized project implementation that knows how to read e.g. include paths from a project file, right? > It doesn't help that Emacs is a very conservative piece of software. A > good example was already given: C++ includes without an extension. By > default, Emacs will open such files in fundamental mode. The GNU libc > actually has local variables comments in their includes just for that > reason! But of course, Qt does not have those, so Emacs cannot parse > those files by default, and people complain about Semantic not parsing > anything. Any other C++ IDE will make that decision for you, but guess > what would happen if we simply modified people's auto-mode-alist? I always thought that magic-mode-alist takes action only after no matches in auto-mode-alist have been found. Maybe that's a worthwhile change to make. Or add a new, third variable, meta-magic-mode-alist, that would take action after auto-mode-alist, when the fundamental mode is picked.