Re: Emacs contributions, C and Lisp

[Phillip Lord]

Jorgen Schaefer <address@hidden> writes:
>> 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?

There's no reason that icons in the fringe should not happen at a
lowever level than this. If they operated as an option on invisible
overlays, this would come for free.


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

Perhaps part of the problem is that there are not enough Emacs libraries
aimed at the programmer. The subprocess support in Emacs provides you
with the primitives that you need, but only that. Getting libraries in
to make life easier for Emacs developers would be a good thing.

A good example of this is dash.el. It's a nice, rich library. Having
started to use it, the only thing that surprises me is that it took so
long for someone to think to write it.


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

CEDET is, of course, the counter example to my theory that more
libraries for programmers would be good. I think you are right, that it
is not as widely used within Emacs as it should be.


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

I think this is not necessarily true. People itch in a lot of strange
ways. 

Phil