From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...) Date: Sun, 16 Feb 2014 18:45:36 +0200 Message-ID: <83wqgv9fbj.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392569150 8981 80.91.229.3 (16 Feb 2014 16:45:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 16 Feb 2014 16:45:50 +0000 (UTC) Cc: dak@gnu.org, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 16 17:45:55 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 1WF4qp-0001Vt-2f for ged-emacs-devel@m.gmane.org; Sun, 16 Feb 2014 17:45:55 +0100 Original-Received: from localhost ([::1]:34063 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF4qo-0001Xu-NV for ged-emacs-devel@m.gmane.org; Sun, 16 Feb 2014 11:45:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF4qg-0001Xn-TC for emacs-devel@gnu.org; Sun, 16 Feb 2014 11:45:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WF4qb-0008Q1-Ga for emacs-devel@gnu.org; Sun, 16 Feb 2014 11:45:46 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:54848) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WF4qU-0008OB-H6; Sun, 16 Feb 2014 11:45:34 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N1300F00KX6IW00@mtaout24.012.net.il>; Sun, 16 Feb 2014 18:44:25 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1300H7XL61CK00@mtaout24.012.net.il>; Sun, 16 Feb 2014 18:44:25 +0200 (IST) In-reply-to: <5300189A.9090208@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:169648 Archived-At: > Date: Sun, 16 Feb 2014 03:47:06 +0200 > From: Dmitry Gutov > CC: dak@gnu.org, emacs-devel@gnu.org > > > First, C is a really simple language, and compilers nowadays are good > > at diagnosing mistakes. > > 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? > > But even if you decide not to go that way, there are a lot of place to > > contribute to the design and the Lisp portions of the implementation. > > Even just formulating the requirements is a huge step forward, IMO. > > Most of the requirements for multiple mode support have been discussed > over the years, and the parent discussion has some details that make the > picture clearer, at least for me. If you think that's insufficient, > please feel free to ask questions, or suggest another format for > recording the requirements. 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. > > Actually, I don't see many new contributors that do it in Lisp, > > either. Sure, there's a lot of code being committed every day, but > > awfully few features that really advance forward Emacs as the > > programming environment. > > 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, and do we even have a roadmap for where we want it to go? > > E.g., witness the lack of any significant > > progress in adding IDE features. > > I guess that depends on what features you expect. 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? (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?) > 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 suitable for those languages. _That_ would really move Emacs forward, towards a point where, hopefully, it will once again be relevant for modern development paradigm and provide what programmers expect. > As far as code completion interface goes, Company development continues. I hope this will some day be bundled with Emacs. (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.) > 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? > 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? > One feature that has seen less attention is refactoring, but there > already are a few packages providing simplistic (and some, even more > complex) refactorings: js2-refactor, ruby-refactor, clj-refactor, traad > and others. Yes, refactoring is very important, and we should have it before we can call ourselves IDE. > What other features are missing? Class diagrams? Yes, that too.