Why bring new features to Emacs and not Emacs to new applications? (was: Emacs as word processor)

Why bring new features to Emacs and not Emacs to new applications? (was: Emacs as word processor)

[Torsten Wagner]

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...

Torwag

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

[Pascal J. Bourguignon]

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/

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

[Lennart Borgman]

On Sun, Nov 24, 2013 at 10:00 PM, Pascal J. Bourguignon
<pjb@informatimago.com> 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?

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

[Pascal J. Bourguignon]

Lennart Borgman <lennart.borgman@gmail.com> writes:

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

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

[Lennart Borgman]

On Mon, Nov 25, 2013 at 12:37 AM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:
>
>>> - 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.

I think we are misunderstanding each other. There are all sort of
events that must be handled. Isn't there loops inside the keyboard
handling now? (Or, do I misremember?)

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

[Pascal J. Bourguignon]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> On Mon, Nov 25, 2013 at 12:37 AM, Pascal J. Bourguignon
> <pjb@informatimago.com> wrote:
>>
>>>> - 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.
>
> I think we are misunderstanding each other. There are all sort of
> events that must be handled. Isn't there loops inside the keyboard
> handling now? (Or, do I misremember?)

Not really.  There's function like read-from-minibuffer, but they're
called explicitely by the commands that are called when receiving
commands asking for minibuffer input, like M-x =
execute-extended-command.

Also, there's what's called recursive edit, where one command loop calls
another embedded command loop, but since it's just a recursive call, it
wouldn't really qualify as a modal loop.

-- 
__Pascal Bourguignon__
http://www.informatimago.com/

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

[Lennart Borgman]

On Mon, Nov 25, 2013 at 9:12 PM, Pascal J. Bourguignon
<pjb@informatimago.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
>> On Mon, Nov 25, 2013 at 12:37 AM, Pascal J. Bourguignon
>> <pjb@informatimago.com> wrote:
>>>
>>>>> - 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.
>>
>> I think we are misunderstanding each other. There are all sort of
>> events that must be handled. Isn't there loops inside the keyboard
>> handling now? (Or, do I misremember?)
>
> Not really.  There's function like read-from-minibuffer, but they're
> called explicitely by the commands that are called when receiving
> commands asking for minibuffer input, like M-x =
> execute-extended-command.

I meant on a lower level in the C code, but I do not remember the
details any more.