Re: Emacs contributions, C and Lisp

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 16 Feb 2014 19:27:56 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: dak@gnu.org, emacs-devel@gnu.org
> 
> On 16.02.2014 18:45, Eli Zaretskii wrote:
> >> 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?
> 
> Manual memory management?

Mostly a red herring in Emacs's C layers, unless you are inventing a
new Lisp data type or mess with GC.

> And when I'm writing Lisp, I usually don't 
> have to worry about standard library including both modern and obsolete 
> (and unsecure!) functions doing the same thing, working with baroque 
> build system and not breaking things on different (often old) compilers 
> and platforms I can't test.

These problems exist in Lisp as they do (or don't) in C, as far as
Emacs is concerned.  E.g., see the latest discussion of crypto
features.

> > 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.
> 
> Ok, I'll try to get around to it in the near future.

Thanks!

> >> 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
> 
> They also share their toys. And many people rely on certain "toys" for 
> their work.

Of course.  And that's OK.  I'm just saying that advancing Emacs needs
more than that.

>  > and do we even have a roadmap for where we want it to go?
> 
> That's a rhetorical question, isn't it?

I guess so.

> > 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?
> 
> hs-minor-mode? outline-minor-mode? I think CEDET also includes something 
> similar.

See the other mail for what I (and Jorgen) had in mind.  I don't
think we have anything like that in Emacs, even with CEDET.  ECB
(which isn't bundled) is the only thing that comes close, but IMO we
should have had this in Emacs core for a long time.

> I dislike code folding, so this is not an area I examined thoroughly.

I don't use it much myself, but it can be invaluable when studying the
structure of a large and complex source file.

> > (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?)
> 
> Speedbar is a part of Emacs, isn't it?

Yes, it is.  But it only does this with lists of files and tags, not
with source buffers.

> >> 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
> 
> Maybe someone who programs in languages it supports well (such as 
> yourself?) can write up a short "quickstart" text, or at least formulate 
> the requirements for one.

I certainly hope so.

> > suitable for those languages.
> 
> I don't really know, but this may be nearly impossible given the current 
> CEDET architecture.

I certainly hope not, but I don't know enough about CEDET.

> >> As far as code completion interface goes, Company development continues.
> >
> > I hope this will some day be bundled with Emacs.
> 
> Maybe it will. But not everything has to be bundled with Emacs.

Things that we consider central and important should be.

> >> What other features are missing? Class diagrams?
> >
> > Yes, that too.
> 
> Again, this is something left up to external tools to implement. I'm not 
> sure if Jedi or OmniSharp implement an editor-agnostic interfaces for 
> this feature, but probably not yet.

CEDET has COGRE that supports this already, at least according to
http://cedet.sourceforge.net/ (search for "UML").  Somewhat clunky and
based on "ASCII art", though.