From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is intellisense features integration in Emacs technically possible? Date: Wed, 22 Jan 2014 18:03:18 +0200 Message-ID: <83fvogf1h5.fsf@gnu.org> References: <1390269670.2888.14.camel@localhost.localdomain> <83zjmpf80o.fsf@gnu.org> <52DED291.60500@online.de> <83txcwfz81.fsf@gnu.org> <87txcw8r9h.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1390406594 9824 80.91.229.3 (22 Jan 2014 16:03:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jan 2014 16:03:14 +0000 (UTC) Cc: andreas.roehler@online.de, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 22 17:03:18 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W60Gs-0005km-0m for ged-emacs-devel@m.gmane.org; Wed, 22 Jan 2014 17:03:18 +0100 Original-Received: from localhost ([::1]:35925 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W60Gr-0003Xp-LU for ged-emacs-devel@m.gmane.org; Wed, 22 Jan 2014 11:03:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W60Gl-0003Wm-Ru for emacs-devel@gnu.org; Wed, 22 Jan 2014 11:03:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W60Gg-000847-Q8 for emacs-devel@gnu.org; Wed, 22 Jan 2014 11:03:11 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:62551) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W60Gg-00083d-IF for emacs-devel@gnu.org; Wed, 22 Jan 2014 11:03:06 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MZT00C008G08P00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Wed, 22 Jan 2014 18:03:05 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZT00CWA8L43F40@a-mtaout22.012.net.il>; Wed, 22 Jan 2014 18:03:05 +0200 (IST) In-reply-to: <87txcw8r9h.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168900 Archived-At: > From: "Stephen J. Turnbull" > Cc: Andreas R=C3=B6hler , > emacs-devel@gnu.org > Date: Wed, 22 Jan 2014 15:28:10 +0900 >=20 > > > Bidirection is at the core of any editor - thanks a lot BTW. > > > Intellisense features must come from accessing the programming > > > languages itself. > >=20 > > Both are extremely important for a modern programmer's editor. = So I > > don't see the difference, really. >=20 > There's a big difference. Specifically, intellisense in the abstra= ct > is basically completion, the change in UI is a SMOP, and people hav= e > shown a lot of interest in the UI. Something will happen, although > I'm not sure how close it will be to Visual Studio. >=20 > 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 "prope= rly > formatted Hebrew" (or Arabic) looks like. Not many folks with thos= e > 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 chunk= s 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=E2=84=A2 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 i= n 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 w= ho > 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 m= e > type" case by case I think you are arguing here that adding Intellisense is a smaller jo= b than the display rewrite or bidi -- in which case I'm in violent agreement.