From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jorgen Schaefer Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...) Date: Mon, 17 Feb 2014 20:31:45 +0100 Message-ID: <20140217203145.71a849f7@forcix.jorgenschaefer.de> 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> <20140216180712.236069f6@forcix.jorgenschaefer.de> <83sirj9cyp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1392665523 28802 80.91.229.3 (17 Feb 2014 19:32:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Feb 2014 19:32:03 +0000 (UTC) Cc: dgutov@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 17 20:32:12 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 1WFTvF-0004Bc-46 for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 20:32:09 +0100 Original-Received: from localhost ([::1]:43850 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFTvE-00006z-A7 for ged-emacs-devel@m.gmane.org; Mon, 17 Feb 2014 14:32:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFTv5-00005i-Ue for emacs-devel@gnu.org; Mon, 17 Feb 2014 14:32:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFTv0-0003Qd-Q5 for emacs-devel@gnu.org; Mon, 17 Feb 2014 14:31:59 -0500 Original-Received: from loki.jorgenschaefer.de ([87.230.15.51]:54345) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFTuv-0003Oh-1S; Mon, 17 Feb 2014 14:31:49 -0500 Original-Received: by loki.jorgenschaefer.de (Postfix, from userid 998) id 152B5201387; Mon, 17 Feb 2014 20:31:47 +0100 (CET) Original-Received: from forcix.jorgenschaefer.de (185-23-225-83.lsn.wtnet.de [185.23.225.83]) by loki.jorgenschaefer.de (Postfix) with ESMTPSA id 22FC3201384; Mon, 17 Feb 2014 20:31:46 +0100 (CET) In-Reply-To: <83sirj9cyp.fsf@gnu.org> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; i486-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 87.230.15.51 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:169712 Archived-At: On Sun, 16 Feb 2014 19:36:30 +0200 Eli Zaretskii wrote: > > The whole code folding infrastructure in Emacs needs work, really. > > The problem, as often with Emacs, is not that it wouldn't exist at > > all, but that there are two dozen solutions that all have different > > shortcomings. > > Then here's a clear bunch of todo items, right? I hope someone will > volunteer. To write yet another folding infrastructure that is deficient in some other way? :-) (Only partly joking; I was thinking about doing this, but then I realized I don't really know the idiosyncrasies of current C dialects well enough to make a good choice there, and then I'd write something that works for Python but not for other things. I'll mull it over in my head and maybe come to a point where I feel comfortable writing yet another infrastructure, but see below.) > > > > 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? > > > > Jedi: https://github.com/tkf/emacs-jedi > > Jedi and Rope: https://github.com/jorgenschaefer/elpy > > nrepl: https://github.com/technomancy/nrepl.el (and others) > > tern: https://github.com/marijnh/tern/tree/master/emacs (and others) > > OmniSharp: https://github.com/sp3ctum/omnisharp-emacs (apparently) > > Why aren't they part of Emacs? I can not answer for the others, but elpy is not part of Emacs for a number of reasons. The most important for me is the slow release cycle of Emacs. The library is still evolving more or less quickly. I do not feel like "freezing" it in the current state for the time it takes for another Emacs release to happen. If with "part of Emacs" you mean "in GNU ELPA", then this would be because a number of the dependencies I'd like to bring in are not in GNU ELPA. This will improve over time as I either replace the dependencies with my own libraries or implementations, or making them optional enough to be acceptable for GNU ELPA. I guess suggesting adding external package archives to be able to enable certain configuration options is politically tricky. There are a few other minor problems for me. For example, my last foray in adding a patch to Emacs was so scary regarding the amount of red tape involved in the whole process that I am somewhat reluctant to commit to doing that regularly. But if the other problems weren't there, I guess I'd get over this quite ok. (Incidentally, copyright assignment is not an issue for me at all. Keeping track of contributors can be, but so far, it's not a problem.) > > As I said in the thread you mentioned, the problem is not that these > > extensions wouldn't exist for Emacs, it's that each and every one of > > them reinvents most of the wheel to get similar features to Emacs. > > Bringing them into Emacs bundle is a significant first step towards > solving the deficiencies, since Emacs maintainers will work with the > authors to fix them, and will continue maintaining them through the > years. If they are left outside, they will continue being on the > fringe. I'm not sure this is true. There are plenty of things already in Emacs that have the same problem. Look at code folding as an example. Emacs already includes outline-minor-mode, hs-minor-mode, and allout-mode, all of which are there for code folding. What deficiencies will be solved by adding *more* minor modes that allow folding inside of code? What are authors of language major modes supposed to do to enable code folding? python.el supports *both* hs-minor-mode and outline-minor-mode, but not allout-mode. Are all extensions meant to support both? Which one are users supposed to learn when they want to use code folding in Emacs? If I want to add the icons in the fringe we talked about, which mode would I extend? All three? How about communicating with a subprocess for completions? python.el already does that. It just uses the inferior Python process, which has a few issues. Has adding this to Emacs done anything to make others not reinvent the wheels all the time? I don't see that. CEDET is in Emacs and provides a lot of infrastructure for IDE development. How many of the libraries above use it? None. Looking at the available data, I have a hard time believing that the main problem here is that these libraries with their half a dozen slightly different reinvented wheels haven't made it into Emacs yet. The problem as far as I can see is that these libraries all exist to scratch someone's particular itch (e.g. I wrote elpy because I needed a better programming interface to Python, no other reason), so no one is going to put in a lot of effort of trying to bring all of those scratchings together and find a common abstraction. And even if someone did, it does not seem to me as if there is any kind of interest in Emacs to decide for one particular interface and declare it as "the way to go". But unless someone sits down and decides for this, wheels will keep getting reinvented. > In any case, clinging with clang clearly makes no sense, if we want > these features in Emacs. You asked why they were not in Emacs. I gave you the reason. I am not arguing whether the decision is good or bad, but after having a few multi-page threads about why clang-based extensions aren't allowed in Emacs, it does not make sense to ask a week later "why aren't they in Emacs?" Regards, Jorgen