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: Mon, 25 Nov 2013 00:37:49 +0100 Organization: Informatimago Message-ID: <87pppptlpu.fsf@informatimago.com> References: <8761rhv7kc.fsf@informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385336351 20101 80.91.229.3 (24 Nov 2013 23:39:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Nov 2013 23:39:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 25 00:39:16 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 1VkjGm-0006Dl-CZ for ged-emacs-devel@m.gmane.org; Mon, 25 Nov 2013 00:39:16 +0100 Original-Received: from localhost ([::1]:48910 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkjGl-0000n8-TT for ged-emacs-devel@m.gmane.org; Sun, 24 Nov 2013 18:39:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39449) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkjGd-0000ig-M4 for emacs-devel@gnu.org; Sun, 24 Nov 2013 18:39:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VkjGX-0002bl-Pg for emacs-devel@gnu.org; Sun, 24 Nov 2013 18:39:07 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:51793) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VkjGX-0002bg-Hy for emacs-devel@gnu.org; Sun, 24 Nov 2013 18:39:01 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VkjGW-00066L-1d for emacs-devel@gnu.org; Mon, 25 Nov 2013 00:39:00 +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 ; Mon, 25 Nov 2013 00:39:00 +0100 Original-Received: from pjb by 90.24.199.117 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Nov 2013 00:39:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 46 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:NmY0NGE3YmU5ZWEyYjgxNDM1NTFiMzI0ODc5YTZjODc3ZmQ1YWEwYw== 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:165670 Archived-At: Lennart Borgman writes: > On Sun, Nov 24, 2013 at 10:00 PM, Pascal J. Bourguignon > wrote: >> >> 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 > > I do not unserstand much on this level, but is not OLE etc designed to > address these difficulties. (But see below.) > >> - 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. > > I guess that is a work that must be done if plugin (or similar > interfaces) should be created. But the main problem is perhaps doing > that efficiently. And in the background, of course. There's also the fact that emacs is implemented in emacs lisp. While it'd be nice to be able to "script" an application in lisp, if it is not implemented in lisp, it is less than optimal, because that means that you can't easily modify the application or hook in every nook and cranny. >> - 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. > > Isn't this an area where Emacs must change? On the contrary, this is the essence of what an emacs is. -- __Pascal Bourguignon__ http://www.informatimago.com/