From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Is intellisense features integration in Emacs technically possible? Date: Thu, 23 Jan 2014 17:13:50 +0900 Message-ID: <87eh3z869t.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1390269670.2888.14.camel@localhost.localdomain> <83zjmpf80o.fsf@gnu.org> <83vbxcfzaa.fsf@gnu.org> <87eh40fx9j.fsf@wanadoo.es> <87wqhso7dj.fsf@fencepost.gnu.org> <87lhy88ojq.fsf@uwakimon.sk.tsukuba.ac.jp> <83eh40f1ei.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1390464915 10704 80.91.229.3 (23 Jan 2014 08:15:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jan 2014 08:15:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 23 09:15:22 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 1W6FRZ-0003Zj-Ex for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 09:15:21 +0100 Original-Received: from localhost ([::1]:39436 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6FRY-0006lH-Kd for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 03:15:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6FRP-0006l9-Mn for emacs-devel@gnu.org; Thu, 23 Jan 2014 03:15:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6FRJ-0004GP-RL for emacs-devel@gnu.org; Thu, 23 Jan 2014 03:15:11 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:44849) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6FRD-0003pv-3y; Thu, 23 Jan 2014 03:14:59 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id CCDE1970A3F; Thu, 23 Jan 2014 17:13:50 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C2017129243; Thu, 23 Jan 2014 17:13:50 +0900 (JST) In-Reply-To: <83eh40f1ei.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:168935 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Date: Wed, 22 Jan 2014 16:26:49 +0900 > > > > By comparison, it's hard to say exactly (depends on what you mean by > > "display") > > I meant the core device-independent portions of it, which in Emacs are > xdisp.c, dispnew.c, dispextern.h, composite.c, and bidi.c -- > everything required for basic layout of text and redisplay. Together > they weigh in at about 45KLOC. This still leaves out other parts, > like fringe.c, image.c, xfaces.c, the font stuff, the menu support, > and the device dependent code (*term.c, *fns.c, etc.). If I add > everything together, I get about 135KLOC in the current development > code (up from about 93KLOC in Emacs 21). > > > but XEmacs's display engine is about 3.5KLOC of C code, of > > which less than 1.5KLOC are in the platform-independent parts. > > Not sure how you get these numbers. Just redisplay.c, redisplay.h, > and redisplay-out.c are about 13KLOC. Maybe our concept of what > constitutes the display engine are very different, or maybe I don't > know how to count lines. No, you're right. It's me that has lived in Japan too long and started counting by 10,000s instead of 1,000s. So the core is about 13KLOC (redisplay.c, redisplay.h, and redisplay-output.c). By contrast, if you take out composite.c and bidi.c (features XEmacs doesn't have), xdisp.c, dispnew.c, and dispextern.h are about 40KLOC, 3X as much. I'm sure by now Emacs has additional features that XEmacs doesn't, but even so that doesn't account for factor of 3. The point is that XEmacs code is very differently factored. Whether overall that's good or bad is in the eye of the beholder, but for two beholders (Bill Perry who did the GTK+ port and helped produce a prototype Qt port) and Andrew Choi (who did "Carbon" ports for both Emacs and XEmacs) praised XEmacs for the ease with which they were able to support new GUI platforms. > Again, this doesn't seem to be relevant at all to the issue at > hand Not as you put it. However, David made a claim that highly factored design could make development slower, and I wanted to put that claim to rest because it's *easy* to factor intellisense given Emacs's current architecture, and I want to argue that people shouldn't argue about how hard it is to do comprehensively. They should just jump in and do the language and features *they* need and let others do what they want to do. (Which I believe is your point, too!) > which is whether introducing intellisense for select languages is or > isn't practically possible in Emacs development.