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: Wed, 22 Jan 2014 18:33:56 +0900 Message-ID: <87iotc8inv.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> <87ob34o2n5.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1390383265 8694 80.91.229.3 (22 Jan 2014 09:34:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jan 2014 09:34:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 22 10:34:30 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 1W5uCY-0001xJ-8N for ged-emacs-devel@m.gmane.org; Wed, 22 Jan 2014 10:34:26 +0100 Original-Received: from localhost ([::1]:34384 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5uCX-0008B5-SX for ged-emacs-devel@m.gmane.org; Wed, 22 Jan 2014 04:34:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5uCO-0008Ak-C1 for emacs-devel@gnu.org; Wed, 22 Jan 2014 04:34:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5uCH-0006mY-14 for emacs-devel@gnu.org; Wed, 22 Jan 2014 04:34:16 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:59824) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5uC8-0006iM-Rc; Wed, 22 Jan 2014 04:34:01 -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 E4427970978; Wed, 22 Jan 2014 18:33:56 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D921C129243; Wed, 22 Jan 2014 18:33:56 +0900 (JST) In-Reply-To: <87ob34o2n5.fsf@fencepost.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:168879 Archived-At: David Kastrup writes: > In the long run, [XEmacs-style factoring of (re-)display > functionality] may have made it harder for XEmacs to keep up with > the changing evolution of desktop environment looks, Unlikely. XEmacs developers just emphasized application functionality over desktop integration (except with X, where ICCCM conformance was an early goal -- of course platforms like Windows and Mac OS X make it easy to conform at that level, whereas in practice ICCCM conformance is impossible). True, the native widget support was poorly done, which made everything except Xt/Athena look like crap when compared with implementing directly as done in Emacs. The widgets look like a 14-year-old boy at a sock hop, never quite able to fit in with the cool kids. But that's because they guy who implemented native widget support thought like a Windows programmer, and didn't really like the idea of delegating to widgets. So his code tries to control everything from the Emacs window level down, in C. Yuck. Not to mention hard to modify at all, let alone beautify. OTOH, Bill Perry's original work on GTK+ support had all the cool stuff -- tear off menus, Glade and GNOME integration, and an FFI for anything that came along later. That all bitrotted because BeOpen went under so financial support for GTK+ did too, and the people who ported to GTK+ v2 again just wanted the toplevel effect of the GTK look, and so didn't do a great job of bringing the cool stuff along with them. N.B. While obviously I have strong opinions on how these things *should* have been done in retrospect, it's not clear to me what was the right thing to do at the time. The main point here is that I think what we would need to improve platform integration is *more* refactoring, not less. > 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. So does Emacs. On the Mac as supplied by MacPorts it looks a lot like a late '90s X application. :-) And spews ugly GTK QA warnings like crazy -- uh, excuse me, like all the other GTK apps. > I am actually grateful that I can compile my Emacs with > --without-toolkit-scroll-bars (why is that only a compile-time > option?) Because nobody really took the Lucid Widget promise of true toolkit independence seriously, and that's probably because they never really delivered on it. It's not really possible to plug and play different toolkits at runtime, although it *is* possible to mix and match at compile time. So you'd have to rewrite lwlib for that kind of feature. > 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. Apparently so. But few of them were XEmacs developers, so that has never been emphasized in XEmacs.