Re: Why bring new features to Emacs and not Emacs to new applications?

[Pascal J. Bourguignon]

Lennart Borgman <address@hidden> writes:

> On Sun, Nov 24, 2013 at 10:00 PM, Pascal J. Bourguignon
> <address@hidden> 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/