[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: Stephen J. Turnbull
Subject: Re: Is intellisense features integration in Emacs technically possible?
Date: Thu, 23 Jan 2014 17:13:50 +0900

Eli Zaretskii writes:

 > > From: "Stephen J. Turnbull" <address@hidden>
 > > 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.

reply via email to

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