Re: Emacs contributions, C and Lisp

[Dmitry Gutov <dgutov@yandex.ru>]

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

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

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

 > and do we even have a roadmap for where we want it to go?

That's a rhetorical question, isn't it?

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

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

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

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

http://cedet.sourceforge.net/setup.shtml is vastly outdated.

http://alexott.net/en/writings/emacs-devenv/EmacsCedet.html seems 
comprehensive, but it's quite long.

> suitable for those languages.

I don't really know, but this may be nearly impossible given the current 
CEDET architecture.

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

It's in GNU ELPA already, and as long as major modes in Emacs provide 
the relevant information, it may be good enough.

I'd much rather have a lean Emacs distribution and an easily accessible 
repository of packages each user can pick and install for themselves.

For most of Emacs enthusiasts I know, Emacs is a DIY kind of tool.

> (I also hope we
> rename it to something more palatable before that happens, because
> having newbies learn that completion-related features are called
> "company-SOMETHING" is voluntarily falling into the same trap as with
> "kill/yank" vs "cut/paste" and "frame" vs "window", except that this
> time we have no excuses.)

Yeah, we probably will.

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

In addition to Jorgen's list:

https://github.com/proofit404/company-jedi/
https://github.com/clojure-emacs/company-cider
https://github.com/proofit404/company-tern

>> There are even several packages that provide support for C/C++ code
>> completion using Clang or libclang. They are older, though, than the
>> ones mentioned above.
>
> And where's _their_ integration with Emacs?

When I say "packages" here, I mean Emacs packages.

Take a look at company-clang in GNU ELPA, for example. Apparently, 
that's as close as Clang is ever going to get to Emacs.

> Yes, refactoring is very important, and we should have it before we
> can call ourselves IDE.

Here, some common infrastructure might be useful indeed.

Although I'd start with a rename/replace-in-project feature that doesn't 
involve grep, find and dired. Or at least doesn't involve them explicitly.

And a similar feature for mass-rename in filenames across the project.

(Replace "project" with "directory" if you will, the directory itself 
could be prompted for. Explicit support for projects is less important.)

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