From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Is intellisense features integration in Emacs technically possible? Date: Wed, 22 Jan 2014 09:13:18 +0100 Organization: Organization?!? Message-ID: <87ob34o2n5.fsf@fencepost.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1390378421 17480 80.91.229.3 (22 Jan 2014 08:13:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jan 2014 08:13:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 22 09:13:47 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 1W5swU-0005vR-KS for ged-emacs-devel@m.gmane.org; Wed, 22 Jan 2014 09:13:46 +0100 Original-Received: from localhost ([::1]:34190 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5swU-0007ju-6O for ged-emacs-devel@m.gmane.org; Wed, 22 Jan 2014 03:13:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38531) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5swM-0007iE-A7 for emacs-devel@gnu.org; Wed, 22 Jan 2014 03:13:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5swE-0007qU-6b for emacs-devel@gnu.org; Wed, 22 Jan 2014 03:13:38 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:38343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5swE-0007qB-0Q for emacs-devel@gnu.org; Wed, 22 Jan 2014 03:13:30 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W5swD-0005mv-6j for emacs-devel@gnu.org; Wed, 22 Jan 2014 09:13:29 +0100 Original-Received: from x2f444fe.dyn.telefonica.de ([2.244.68.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Jan 2014 09:13:29 +0100 Original-Received: from dak by x2f444fe.dyn.telefonica.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Jan 2014 09:13:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: x2f444fe.dyn.telefonica.de X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:FH7fJzz512Uf7D+kWkyBL68GtTY= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:168876 Archived-At: "Stephen J. Turnbull" writes: > I apologize for responding to DAK's post but I lost Óscar's. > > > Óscar Fuentes writes: > > > > > Eli Zaretskii writes: > > > > > >> The Emacs display engine is many tens of thousands of C code plus many > > >> thousands of Lisp. > > > > > > AFAIU this is largely a consequence of the development baggage of Emacs. > > > That is, the complexity of the current code base is far greater than the > > > complexity of its purpose. > > It could surely be a lot smaller if it were restricted to a single > multiplatform toolkit such as wxWindows. However, users seem to > prefer platform-specific code, leading to a lot of duplication. It's > not clear to me that's bad, given that both user preference and > developer skills are often very platform-specific. > > By comparison, it's hard to say exactly (depends on what you mean by > "display"), but XEmacs's display engine is about 3.5KLOC of C code, of > which less than 1.5KLOC are in the platform-independent parts. IIUC correctly, XEmacs' display engine factors quite more code and behavior into a platform independent part of the code base. From an engineering and maintenance perspective that seems like a sane thing to do and certainly factored in significantly in the headstart XEmacs had over Emacs regarding the support of graphical interfaces. In the long run, it may have made it harder for XEmacs to keep up with the changing evolution of desktop environment looks, never mind how little this may have actually to do with engineering or usability. XEmacs looks a lot like XEmacs on every platform, or at least it did so when I looked at it the last time, admittedly considerable time ago. And that look makes it quite more apparent that XEmacs was competing with the likes of the Athena widget set and Motif than one can see with Emacs. I am actually grateful that I can compile my Emacs with --without-toolkit-scroll-bars (why is that only a compile-time option?) and get the Lucid scrollbars for my otherwise GTK+ Emacs since, ugly looks aside, the semantics of the old Athena scrollbar design are vastly superior over that of the prettier GTK+ scrollbars, and the GTK+ maintainers are usually quite opposed to provide configurability. But as the user interface wars we had in Emacs alone over the issue of whether the scrollbar should be to the left or the right side of the window show, for a lot of people blending into the respective environment feels very important. -- David Kastrup