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: Emacs contributions, C and Lisp Date: Sun, 16 Feb 2014 19:27:56 +0200 Message-ID: <5300F51C.7040204@yandex.ru> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <52FCD2B4.5080006@yandex.ru> <52FD9F1D.50205@yandex.ru> <83mwhucg1h.fsf@gnu.org> <878ute589i.fsf@fencepost.gnu.org> <83d2iqc84m.fsf@gnu.org> <87wqgxkcr9.fsf@yandex.ru> <834n41db0d.fsf@gnu.org> <52FE2985.4070703@yandex.ru> <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1392571699 4612 80.91.229.3 (16 Feb 2014 17:28:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Feb 2014 17:28:19 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 16 18:28:28 2014 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 1WF5Vy-00008a-1Y for ged-emacs-devel@m.gmane.org; Sun, 16 Feb 2014 18:28:26 +0100 Original-Received: from localhost ([::1]:34351 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF5Vx-0003sG-Lk for ged-emacs-devel@m.gmane.org; Sun, 16 Feb 2014 12:28:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF5Vr-0003s3-2Q for emacs-devel@gnu.org; Sun, 16 Feb 2014 12:28:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WF5Vm-0003LA-AW for emacs-devel@gnu.org; Sun, 16 Feb 2014 12:28:18 -0500 Original-Received: from mail-ee0-x234.google.com ([2a00:1450:4013:c00::234]:64181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF5Vb-0003Iu-Or; Sun, 16 Feb 2014 12:28:04 -0500 Original-Received: by mail-ee0-f52.google.com with SMTP id e53so6617493eek.11 for ; Sun, 16 Feb 2014 09:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=I3DTLK9JTHqLrAz8UYUZh3HtQWqQUq+V2070cY7hjrc=; b=Kn1vkT+lAxhGFoSjW7vt7ClmYZ0tSjDRSBWC4b6QuSsOatqzcEt/UObiPsmBK9PhlG GU6gL85L7JrQsrxbcl8MEJD4CyD/6+Z+CcigzRnmYTOue5C2SeUHBudQmEMJsSF6NaZJ I3rDfXgDYEiFToyPf7KxBXhwd7Z1MpSsz6sV4oVBuZRasTe7/GZdvPCo/yO3fhwsfdHK T4cg1J+7gzvoxVORF0VyjgQIRYwf6wKo7dfojR4jk4+PH353EdIK+xyjl1yGcoUz9Yhs PcFB2Ee7AwXQTBGNISc/SsP9wa9C45tiPFITm8C1LxgDy94FdwGiGHyHTpNlCGgzQGgv CtNA== X-Received: by 10.15.22.65 with SMTP id e41mr22142384eeu.5.1392571682563; Sun, 16 Feb 2014 09:28:02 -0800 (PST) Original-Received: from [192.168.10.2] ([93.109.195.252]) by mx.google.com with ESMTPSA id 46sm46841383ees.4.2014.02.16.09.28.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 09:28:01 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <83wqgv9fbj.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::234 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:169650 Archived-At: On 16.02.2014 18:45, Eli Zaretskii wrote: >> People like to say that, but C being simple and having a weak typing >> system just means one has to learn more things beyond the language >> syntax itself. > > Not sure what you mean. Also, how is this different from Lisp? Manual memory management? And when I'm writing Lisp, I usually don't have to worry about standard library including both modern and obsolete (and unsecure!) functions doing the same thing, working with baroque build system and not breaking things on different (often old) compilers and platforms I can't test. > What I would suggest is to collect the requirements in a single list, > and file a wishlist bug report with them. I wouldn't expect > interested people, if there are any, to glean the requirements from > that longish discussion. Ok, I'll try to get around to it in the near future. >> You may want to look at the Emacs community at large, not limited to the >> core. There are a lot of packages created and added to MELPA, every week. > > Yes, everybody plays with their favorite toys. But how does this > advance Emacs They also share their toys. And many people rely on certain "toys" for their work. > and do we even have a roadmap for where we want it to go? That's a rhetorical question, isn't it? > There was a discussion about this some time ago, although I cannot > find it now. But how about starting with those GUI code folding > decorations like every IDE nowadays has, while Emacs doesn't? hs-minor-mode? outline-minor-mode? I think CEDET also includes something similar. I dislike code folding, so this is not an area I examined thoroughly. > (ECB > comes close, but why shouldn't an Emacs user have that out of the box, > especially when Speedbar does something very similar for ages?) Speedbar is a part of Emacs, isn't it? >> It's true that CEDET hasn't seen a lot of progress feature-wise lately, >> but that's not very surprising: it's complex, it's relatively hard to >> set up for a novice, it has a weird separation of extra features between >> the versions in Emacs and its own trunk, and it's not really suitable >> for dynamic languages, or languages with type inference. AFAIK, that is. > > Then the immediate task would be to make it simpler to set up and Maybe someone who programs in languages it supports well (such as yourself?) can write up a short "quickstart" text, or at least formulate the requirements for one. http://cedet.sourceforge.net/setup.shtml is vastly outdated. http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html seems comprehensive, but it's quite long. > suitable for those languages. I don't really know, but this may be nearly impossible given the current CEDET architecture. >> As far as code completion interface goes, Company development continues. > > I hope this will some day be bundled with Emacs. Maybe it will. But not everything has to be bundled with Emacs. It's in GNU ELPA already, and as long as major modes in Emacs provide the relevant information, it may be good enough. I'd much rather have a lean Emacs distribution and an easily accessible repository of packages each user can pick and install for themselves. For most of Emacs enthusiasts I know, Emacs is a DIY kind of tool. > (I also hope we > rename it to something more palatable before that happens, because > having newbies learn that completion-related features are called > "company-SOMETHING" is voluntarily falling into the same trap as with > "kill/yank" vs "cut/paste" and "frame" vs "window", except that this > time we have no excuses.) Yeah, we probably will. >> Despite certain expectations that everything is better when written in >> Emacs Lisp, context-dependent code completion and documentation display >> support is usually delegated to an external process, and there are >> relatively new packages that use editor-agnostic services: Jedi for >> Python, nREPL for Clojure, Tern for JavaScript, OmniSharp for C#. > > Where's their integration with Emacs, though? In addition to Jorgen's list: https://github.com/proofit404/company-jedi/ https://github.com/clojure-emacs/company-cider https://github.com/proofit404/company-tern >> There are even several packages that provide support for C/C++ code >> completion using Clang or libclang. They are older, though, than the >> ones mentioned above. > > And where's _their_ integration with Emacs? When I say "packages" here, I mean Emacs packages. Take a look at company-clang in GNU ELPA, for example. Apparently, that's as close as Clang is ever going to get to Emacs. > Yes, refactoring is very important, and we should have it before we > can call ourselves IDE. Here, some common infrastructure might be useful indeed. Although I'd start with a rename/replace-in-project feature that doesn't involve grep, find and dired. Or at least doesn't involve them explicitly. And a similar feature for mass-rename in filenames across the project. (Replace "project" with "directory" if you will, the directory itself could be prompted for. Explicit support for projects is less important.) >> What other features are missing? Class diagrams? > > Yes, that too. Again, this is something left up to external tools to implement. I'm not sure if Jedi or OmniSharp implement an editor-agnostic interfaces for this feature, but probably not yet.