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: Fri, 24 Jan 2014 11:57:42 +0900 Message-ID: <8761pa84t5.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> <87eh3z869t.fsf@uwakimon.sk.tsukuba.ac.jp> <83vbxaekmw.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 1390532278 11289 80.91.229.3 (24 Jan 2014 02:57:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jan 2014 02:57:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 24 03:58:04 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 1W6Wy3-0007nl-U0 for ged-emacs-devel@m.gmane.org; Fri, 24 Jan 2014 03:58:04 +0100 Original-Received: from localhost ([::1]:44163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6Wy3-0003Tv-IH for ged-emacs-devel@m.gmane.org; Thu, 23 Jan 2014 21:58:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6Wxw-0003S5-JD for emacs-devel@gnu.org; Thu, 23 Jan 2014 21:58:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6Wxr-0005Gk-Fg for emacs-devel@gnu.org; Thu, 23 Jan 2014 21:57:56 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:55301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6Wxl-0005F1-Ih; Thu, 23 Jan 2014 21:57:45 -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 C5C3C970905; Fri, 24 Jan 2014 11:57:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BA3EF129243; Fri, 24 Jan 2014 11:57:42 +0900 (JST) In-Reply-To: <83vbxaekmw.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:168991 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Cc: emacs-devel@gnu.org > > Date: Thu, 23 Jan 2014 17:13:50 +0900 > > > > 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. > > Not sure it's worth to continue this line counting, but just for the > record: AFAIU, you should add more XEmacs files to the "core", because > xdisp.c covers some areas which in XEmacs are on separate files. No, that's backwards to my point. I don't care if XEmacs has less code to support redisplay than Emacs does (modulo the "less functionality" aspect, I'd be disappointed if the comparison isn't approximately proportional to functionality). My point is precisely that Emacs's "core" is much bigger than XEmacs's because it includes additional functionality. Of course in C (and most languages) division into files is rather arbitrary. Perhaps the size of xdisp.c *doesn't* reflect substantially greater coupling among the functions it defines. But division into more files does help the developer to *reduce* coupling (by use of "static" to remind her that this variable shouldn't be used outside of this file, for example). And reduced coupling often leads to easier porting.