From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.devel Subject: Re: Why bring new features to Emacs and not Emacs to new applications? Date: Sun, 24 Nov 2013 22:00:35 +0100 Organization: Informatimago Message-ID: <8761rhv7kc.fsf@informatimago.com> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385326920 24788 80.91.229.3 (24 Nov 2013 21:02:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Nov 2013 21:02:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 24 22:02:05 2013 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 1Vkgoe-0004UH-IW for ged-emacs-devel@m.gmane.org; Sun, 24 Nov 2013 22:02:04 +0100 Original-Received: from localhost ([::1]:48512 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkgoe-0000kz-03 for ged-emacs-devel@m.gmane.org; Sun, 24 Nov 2013 16:02:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkgoV-0000kc-Cm for emacs-devel@gnu.org; Sun, 24 Nov 2013 16:02:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkgoP-0003S9-84 for emacs-devel@gnu.org; Sun, 24 Nov 2013 16:01:55 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:33022) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkgoO-0003Rz-SL for emacs-devel@gnu.org; Sun, 24 Nov 2013 16:01:49 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VkgoL-0004Ll-U5 for emacs-devel@gnu.org; Sun, 24 Nov 2013 22:01:45 +0100 Original-Received: from 90.24.199.117 ([90.24.199.117]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Nov 2013 22:01:45 +0100 Original-Received: from pjb by 90.24.199.117 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 24 Nov 2013 22:01:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 92 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 90.24.199.117 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:ZmI1MTYwMTA1Y2IwYzZhNjA5YjE2M2Q5OTAwNzFlOThmNWRlNWYxYg== 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:165666 Archived-At: Torsten Wagner writes: > Hi, > I normally only lurk around on the mailing list. However, this > discussion reminded me very much about some ideas/thoughts I had every > now and then. > > First emacs is poweful and feature rich. If you got used to it, its > hard to use any other editor. > > Secondly, some other projects try to mimic emacs already. Take > eclipse, which has an emacs-mode plug-in, firefox has an emacs > plug-in, etc. > Most of those mimic the most common keyboard shortcuts to make emacs > users feel home. > > So instead of creating just emacs mode or core feature to emacs, why > not make sure others can embedded a real emacs session within there > application? > > Take the example above, eclipse does a nice project management job > (never got warm with emacs sidebar and cedet). Now combine this with > emacs as an editor. > There are so many IDEs out there for so many different purposes, who > just miss a good editor. Same might be true for many other programs > and applications. > > Thus, if there would exsist something like a emacs widget for the > usual GUI toolkits or an emacs library which gives all the power of > emacs to other applications, one could think of a e.g. a > libre-office-emacs office suite. A thunderbird-emacs mailer or > something as small as a emacs-arduino IDE. > > Just my two (non-developer) cents... As Richard mentionned, the other applications are not necessarily structured in a way that is receptive to include a lisp engine and hook easily with it. This would probably be at least as complex as implementing a word processor in emacs. For example, if an application is written in C++ (often the case nowadays), and use templates (also often the case if they use C++), then you already have a major stumbling block, in interfacing Lisp with C++ thru a FFI: Lisp has a dynamic nature where the objects are created at run-time, while C++ templates are instanciated at compilation time. If an API of the application takes as argument an instance of a template class, then you need to compile with C++ the template of the new lisp object class (its representation in C++). So either you wrap your lisp objects in a predefined set of C++ objects, or you have to invoke the (same) C++ compiler (that was used to compile the application) at run-time and dynamically load a library with the new template instances, just to call a function in the application. Otherwise the difficulties may be: - bad or lacking internal API, The worst would be big balls of mud, lacking internal APIs. This doesn't seem to be the case of LibreOffice, or Firefox for example, but some programs are just horrible inside. - lisp hostile data structures, Lisp use a garbage collector and typed objects, while other programming languages often use instead manual memory management and typed variables. Keeping both structures consistent in parallel would be a lot work. Also, an application not designed for introspection can easily not provide accessors to its internal data structures, apart from the constructors and visitors it needs to implement its algorithms. You get opaque objects with which you cannot do anything, or with which you can only work at too coarse a level. If the way to extend an application is to provide it a subclass of some of its C++ class, it may prove to be a challenge to provide a C++ subclass defined from lisp code. - incompatible control structure. While most applications will have like emacs a main event loop, it is not designed usually to go thru (dynamically modifiable) keymaps to handle in a uniform way the events, but would rather rely on frameworks, which may implement their own modal control loops. So it's obviously not as simple as compiling the application with -lecl and calling cl_boot(argc,argv); -- __Pascal Bourguignon__ http://www.informatimago.com/