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

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Torsten Wagner <torsten.wagner@gmail.com> 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/