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: Fri, 24 Jan 2014 09:43:42 +0200 Message-ID: <83k3dpesep.fsf@gnu.org> 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> <8761pa84t5.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1390549414 20699 80.91.229.3 (24 Jan 2014 07:43:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jan 2014 07:43:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 24 08:43:40 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 1W6bQS-0006vW-9k for ged-emacs-devel@m.gmane.org; Fri, 24 Jan 2014 08:43:40 +0100 Original-Received: from localhost ([::1]:44905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6bQR-0005gF-U2 for ged-emacs-devel@m.gmane.org; Fri, 24 Jan 2014 02:43:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6bQJ-0005XP-IK for emacs-devel@gnu.org; Fri, 24 Jan 2014 02:43:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W6bQE-0001JG-EQ for emacs-devel@gnu.org; Fri, 24 Jan 2014 02:43:31 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:38790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W6bQE-0001JA-66 for emacs-devel@gnu.org; Fri, 24 Jan 2014 02:43:26 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MZW00E00AE1OR00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 24 Jan 2014 09:43:24 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MZW00EL4ASBQ000@a-mtaout20.012.net.il>; Fri, 24 Jan 2014 09:43:24 +0200 (IST) In-reply-to: <8761pa84t5.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.166 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:168996 Archived-At: > From: "Stephen J. Turnbull" > Date: Fri, 24 Jan 2014 11:57:42 +0900 > Cc: emacs-devel@gnu.org > > > 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. Perhaps you could explain why this matters in the context of this discussion. As long as the file is clearly separated into sections that deal with different groups of functionality, the size of the file should matter only to the compiler, no? > 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). It's actually the other way around: the larger the file, the more functions can be static, even if they are interfaces between conceptually separate modules in the program's architectural design, and will have to have external linkage if a large file is subdivided into several smaller ones.