[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Dmitry Gutov
Subject: Re: Emacs contributions, C and Lisp
Date: Sun, 16 Feb 2014 19:27:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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.

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:


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]