[Top][All Lists]

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

Re: Is intellisense features integration in Emacs technically possible?

From: Tom
Subject: Re: Is intellisense features integration in Emacs technically possible?
Date: Tue, 21 Jan 2014 19:58:21 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Eli Zaretskii <eliz <at> gnu.org> writes:

> According to this logic something like the rewrite of the display
> engine that happened between Emacs 20 and Emacs 21, or bidirectional
> editing support for Emacs 24 would never have happened.  But it did.
> Each one of these took many man-months of work.

Yes, but I don't think their complexity is comparable to, for example,
the Java support of Eclipse which has been continously developed
for many years by a bunch of people. Repeating this effort is
no small feat. 

> Look at the amount of changes that get committed every day to the
> Emacs repository, and try to estimate the effort that goes into that.
> Sometimes I wish I had such resources at my disposal on my daytime
> job.

Yet, Emacs cannot provide the same level of language support like
other tools for Java and C++, so it is apparent the language support
part has not enough resources.

> I think the shortage is not in development resources, but in motivated
> individuals who'd sit down and do the job, and lobby others to come on
> board and help.  Volunteers are welcome.

Motivation can have multiple forms. For example, my idea was financial


The idea is to make it possible for people to sponsor specific 
features and there is enough bounty then someone will come and
do it. If people don't want to work on them in their free time,
then users can create a money pool (everyone giving a small
amount) and if enough users donates money then someone can work
on it full time until the feature is implemented.

> Personally, I think implementing such features via external programs
> is a terrible design.  It will never be smooth and responsive enough,
> and on top of that you'd need to track development of those other
> tools.  

I agree a native solution would be better, but for Java Eclim provides 
these features right now, while a native solution (if it happens at all)
will provide them next year, or a year after that?


> And what if they become abandoned some day?

These interface packages should not be complicated. They
just talk to the server and then present the data to an emacs 
frontend (like autocomplete). So if a tool is abandoned then
there is an other tool instead, and only this interface
layer needs to be reimplemented which shouldn't be a lot 
of work.

reply via email to

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