Emacs Plugin

[Fren Zeee]

Emacs Plugin

An Emacs Plugin is platform dependent code, probably written in c,
that is dynamically loaded as an OS “library” through a
ForeignFunctionInterface?  to accomplish goals that are usually
outside the scope of Emacs. Mostly this means buffers could contain
the core functionality of a wide variety of applications.

Examples include:

    * Video/Audio player and editor.
    * Image editor as part of the viewer. Some suggested technologies:
http://XaraXtreme.org , InkScape, Gimp, GraphicsMagick?
    * Browse and mail with the Gecko engine. Never start FireFox or
ThunderBird? again.
    * This might even work for games. Should probably have the option
to ‘pause’ the execution and even ‘page-out’ the memory when you
switch away from that buffer.

>From WishList

It would be really cool, if the emacs display engine would support the
drawing of circles, lines, boxes. This would allow the creation of
vector graphics within emacs. It would be enough to have some graphics
only buffers for a start. With such an addition one could write a xfig
mode. Well, I am only dreaming. – StefanReichoer

    * You can create images (using ‘create-image’) and insert them
into buffers (using ‘put-image’) within Emacs. You could also fix the
Emacs redisplay engine such that stuff created via the XlibInterface
(see PixelDrawing) do not get erased on the next redisplay. –
AlexSchroeder
    * Whatever you do, the Emacs display engine is line-oriented, for
editing text. It’s clearly not suitable as a vector graphics editor,
and why should it be?
    * Rather than asking emacs to become half vector-graphics editor,
I’d like to see emacs support, as modules, buffers of types other than
text. – TomBreton
    * So in your vector-graphics example, you would write your circle,
box etc drawing code, and you’d write a data structure and tell emacs
that it was a type of buffer and should be displayed via your display
code, all without changing emacs itself.
    * And if your extension was horrendous, nobody else is bothered;
if it was a niche thing, others who like it can load it or link it in
and still share the rest of emacs with everyone else; and if it’s nice
it’s easy to include it later in emacs proper.
    * Some thoughts towards implementation:
          o Each such module would supply its own data representation
(Model) and display engine that would assume it was dealing with an
emacs window (View), and data inspection and mutation primitives
controlled via elisp (Controller).
          o Some existing buffer fields would be common to all buffer
types (eg buffer name, save_modified, modtime, auto_save_modified,
backed_up, etc), some would be heterogeneous but retain a common
structure (eg undo_list, markers), and some would become specific to
text buffers (eg last_window_start, display_table, syntax_table_v).
          o Like buffer, window would share some existing fields
(most), structurally share some (pointm, last_point, region_showing),
and some would become specific to text (start, display_table,
base_line_number, base_line_pos).
          o C functions that now assume a buffer is a text-buffer
would check buffer type before proceeding. Fset_window_buffer (I
think, looking at window.c) would know to call a non-text buffer’s own
display function. – TomBreton
    * You can make SVG images with lisp and display them in Emacs
buffers. See EmacsSvg.See EmacsXembed for work on embedding other
applications inside Emacs – JoakimVerona