From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Why bring new features to Emacs and not Emacs to new applications? Date: Sun, 24 Nov 2013 22:20:28 +0100 Message-ID: References: <8761rhv7kc.fsf@informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1385328059 3662 80.91.229.3 (24 Nov 2013 21:20:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Nov 2013 21:20:59 +0000 (UTC) Cc: Emacs-Devel devel To: "Pascal J. Bourguignon" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 24 22:21: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 1Vkh73-0003Ke-6P for ged-emacs-devel@m.gmane.org; Sun, 24 Nov 2013 22:21:05 +0100 Original-Received: from localhost ([::1]:48564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkh72-0005ga-MR for ged-emacs-devel@m.gmane.org; Sun, 24 Nov 2013 16:21:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkh6y-0005gN-OT for emacs-devel@gnu.org; Sun, 24 Nov 2013 16:21:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vkh6x-0000E1-GR for emacs-devel@gnu.org; Sun, 24 Nov 2013 16:21:00 -0500 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:54675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vkh6x-0000Dm-8f for emacs-devel@gnu.org; Sun, 24 Nov 2013 16:20:59 -0500 Original-Received: by mail-wi0-f176.google.com with SMTP id hq4so2767019wib.9 for ; Sun, 24 Nov 2013 13:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hCXmzh0pSktOXe3KyuiREEgaCYWpAf556wC6HGeMUMM=; b=whEh1vMUUjIwYafWHfmcYjiF7MPvOfIo3uQ4izamUDzU9mJSMPxK4ejBlGu0EE+m6l M9gaG5bZg2kRJHphzMfR8LJNrJtmYhPpXJp56dElTlsMeiK0057Xyrl6DmWRXvMlk3y1 TrV6xjWspGW0WQawfpAYvkugDO1xkogVC5aw13halj1hUkm0YqoiP/h6vaPNGPnKgrFn uCDQjW3H3RlL+4iTNcPrkxcLMAUNpKtbJI7Eyik66Ja44BOpNBk4EJl8+A0AdefYmdBS olxYi4R81inNRIHDMMRx4YCDzSHgaFbMQLKSqUR+imfYy24DIacPyM9TcCbwDaRVymnJ hQoQ== X-Received: by 10.180.108.42 with SMTP id hh10mr10997354wib.15.1385328058493; Sun, 24 Nov 2013 13:20:58 -0800 (PST) Original-Received: by 10.194.216.227 with HTTP; Sun, 24 Nov 2013 13:20:28 -0800 (PST) In-Reply-To: <8761rhv7kc.fsf@informatimago.com> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 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:165669 Archived-At: 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. > - 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?