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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 17 Feb 2014 20:31:45 +0100
> From: Jorgen Schaefer <forcer@forcix.cx>
> Cc: emacs-devel@gnu.org, dgutov@yandex.ru
> 
> On Sun, 16 Feb 2014 19:36:30 +0200
> Eli Zaretskii <eliz@gnu.org> 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? :-)

No, improve one of the existing ones (outline-mode or hs-mode, for
example).

> (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.)

I would suggest starting with just the visual indicators, and leaving
the automatic detection of code blocks for a later changeset.

> > > 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.

Since many people and GNU/Linux distros use the development snapshots,
I don't see why this would be a problem.

> 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.

What red tape?  Emacs is about the most red-tape-less project as you
can find, as far as the procedure of admitting a patch is considered.

> > > 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.

I am.

> There are plenty of things already in Emacs that have the same
> problem.

Please point them out.  I'm quite sure they were in much worse shape
before.

> 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?

I didn't suggest adding one more mode, I suggested to pick one and add
the features discussed to it.

> 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?

Only one, IMO, certainly for starters.

> CEDET is in Emacs and provides a lot of infrastructure for IDE
> development. How many of the libraries above use it? None.

I'm still waiting to see someone (you?) to put their money where their
mouth is, and actually start working on that.

> 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 I see it is that no one steps forward to advance all
the ideas to the state where others could actually use these features.
The moment that happens, these problems will be over, and people will
quickly switch to the package which offers them and drop the
alternatives.

> 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.

If you mean that we also need more leadership in these matters, then I
agree.

> > 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?"

I didn't know they were based on clang when I asked, that's all.