Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...)

[Jorgen Schaefer]

On Sun, 16 Feb 2014 19:36:30 +0200
Eli Zaretskii <address@hidden> 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