Re: Is intellisense features integration in Emacs technically possible?

[Stephen J. Turnbull]

Eli Zaretskii writes:

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

Your math is correct, your statistics suck.  Given that developer
residence is *highly* biased toward living in the US, you can't just
multiply fraction of Java developers by fraction of R2L region
residents (and what does Java skill have to do with developing for
Emacs, may I ask?)

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

True, but I didn't say there was a good *implementation*, I said there
was a good *algorithm*, which you yourself chose to implement.
Subject to this caveat:

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

Sure, it ain't easy, but that was *my* point, no?  That's *why* you
need not only the *desire* to have it in Emacs and the *knowledge* of
bidi to recognize a bug when you see it, but you *also* need a fairly
high level of understanding of Emacs redisplay.  Nor was there really
a choice of algorithm was there?  You still promise to get the same
results, right?  And people would complain if you didn't, right?

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

I didn't say "once-and-for-all", and there's no way I would: I'm a guy
who can cite chapter and verse (ok, with the help of the IETF website)
of the differences among the past versions and future candidates for
STD 11 (ie, RFCs 632, 733, 822, 2822, and 5322) -- I know there's no
"once-and-for-all" in computing.

BTW, they slipped that one past me.  My condolences.  But it certainly
shows you're a promise-keeper that you even think about trying to keep
up with that moving target.

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

How many people are there with the energy, knowledge, and stubbornness
to reengineer a batch algorithm for use in Emacs redisplay?  I stand
by my statement.  This was not a job to be dismissed with "the rest is
a SMOP.  Why do I (who only dream of being able to do it) have to tell
you?

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

Not my point at all.

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

With the emphasis on "violent".  Love you too, Eli!  :-)  Happy (and
productive!) New Year to you!  And don't spend it all on UBA updates!

Steve