Re: Is intellisense features integration in Emacs technically possible?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Andreas Röhler <address@hidden>,
>     address@hidden
> Date: Wed, 22 Jan 2014 15:28:10 +0900
> 
>  > > Bidirection is at the core of any editor - thanks a lot BTW.
>  > > Intellisense features must come from accessing the programming
>  > > languages itself.
>  > 
>  > Both are extremely important for a modern programmer's editor.  So I
>  > don't see the difference, really.
> 
> There's a big difference.  Specifically, intellisense in the abstract
> is basically completion, the change in UI is a SMOP, and people have
> shown a lot of interest in the UI.  Something will happen, although
> I'm not sure how close it will be to Visual Studio.
> 
> What's left to compare is necessary skills.  Adding bidirection
> requires intimate knowledge of both UAX#9 and the Emacs display
> engine, and greatly benefits from a native knowledge of what "properly
> formatted Hebrew" (or Arabic) looks like.  Not many folks with those
> qualifications, or who want to acquire them.

With around 550 million people speaking R2L languages world wide, I
think "not many" is somewhat accurate.  According to this:

  http://java.dzone.com/articles/how-many-java-developers-are

there are between 6.8 and 10.7 million Java developers in the world,
out of 5 billion people living in developed regions, which means tens
of thousands of Java developers in R2L cultures.  All of them are
potential candidates to want this in Emacs (and that's for Java
alone).  I won't be surprised if the numbers for Python or Ruby or C++
are higher.

> It also may as well be done all-at-once because UAX#9 exists -- we
> don't need to fool around and figure out what is a good algorithm.
> We already have a good one, the only question is whether our
> implementation is correct.

Not true.  All the implementations of the UBA I know of are not good
for Emacs, because they are batch implementations: they reorder chunks
of text in one go.  By contrast, the Emacs display engine examines
buffer text one character at a time, and so needed a _sequential_
implementation of the UBA.  Moreover, the UBA itself is described in
the Unicode Standard assuming batch-style reordering, evidently
because it was written by people who either don't understand the
difference between requirements and implementation, or didn't bother
to formulate requirements, assuming that only batch-style
implementations will be needed anyway.

So the job actually constituted mentally reverse-engineering the UBA
to formulate the missing requirements, then implementing that.

And, to add insult to injury, Unicode 6.3 made 2 significant changes
in the UBA, which means Someone™ will now have to go back and extend
all that to support the new features.  Not really a once-and-for-all
job, I'd say.

> So it's a big job few can tackle.

Not sure how you took this leap of logic: if the algorithm is clear,
why shouldn't it be possible for more than "a few" to come up with a
suitable implementation?  And in fact, at the time the bidi support in
Emacs was actively discussed (I'm talking around 2001), there were at
least 3 candidate implementations proposed, and 2 of them were
actually prototyped in Emacs.  More than enough to start with.

And still, nothing happened for 10 more years.  So clearly, other
factors are at work that determine if and when some major feature is
implemented in Emacs.

> Adding a new language to intellisense, OTOH, is something anybody who
> uses the language and knows enough Elisp to write defuns in their
> .emacs can help with.  Nor does it need to be done all-at-once, as
> long as the basic interface makes it easy to say "shut up and let me
> type" case by case

I think you are arguing here that adding Intellisense is a smaller job
than the display rewrite or bidi -- in which case I'm in violent
agreement.