A plea for dynamically loadable extension modules

[Mario Lang]

Hello.

I'd like to re-raise discussion about this topic by explaining
my current situation and the problems arising from it.

I am writing bindings for the GNOME Assistive Technology Service
Provider Interface, a library which allows querying of the GNOME
desktop and extracting information about various objects on the desktop.
Emacs is my favourite User Interface, so I'd like to eventually
make those bindings available to elisp.

Currently, I wrote the bindings for Guile, so that I can call
the underlying C functions from Scheme.
I then used some code from the guile CVS which interfaces
Guile to Emacs Lisp by running a Guile process as external program.
However, this code has several problems:

1. It does not handle multiline strings correctly.  When a string
containing a \n is received, the parser fails on the elisp side.

2. Scheme does to my knowledge not have a way to produce
equivalents to lisp's keywords.  I had to introduce
a re-search-forward/replace-match loop which replaces
{#:.*} with :.*.  This way I can say #:tag in scheme, and get
:tag in elisp.

3. I do nto see a way to work with non-standard object types.
For instance, my bindings to GNOME's AT-SPI use a smob in Scheme
which holds the pointer to the actual objects in AT-SPI.
So, upon executing a function like (desktop 0) I get
#<Accessible 0xsomehexaddr role=unknown>
which is the printed representation of my internal smob.

However, I can not pass those objects to emacs lisp and vice versa,
which makes programming for these bindings in elisp directly
very hard.  What I'd need to do is create some kind of
cache on the scheme side which allows to reference those objects
by something else, like a id or something.  This is hackish, and
not something I particularily want to do.

However, there are several attempts to extend emacs
in a way which allows to load bindings to other C routines
dynamically.  I particularily remember Dave Love's patch,
which utilized libtool AFAIK.
However, I can only use those extentions to impelemnt what I want
if they are integrated into Emacs.  The whole point of
using such an extention is to avoid that the user has
to recompile Emacs.  Emacs is a large system, and many people
just do not want to mess with their existing Emacs installation.
So if I'd write my bindings to AT-SPI either as Emacs patch,
or as something which uses Dave's loader extention, in both
cases, the user would need to patch and recompile emacs, which
is not really good IMHO, because it would lower the
chance of people using my code.  Additionally, it also makes
it hard for distributions to include my code, since they'd need to
merge it with their emacs package, which is something they probably do not
want to do.

Is there any chance that we get the dynloading extention
for 21.4?  If not, could you please explain why?

Some people might think now: "Why use an editor to
do your project?"  Well, Emacs is an editor right, but
it is also an platform independent, and mostly user interface
independent programming environment.  Code I write in 
emacs lisp runs usually equally well either under X,
or under text interfaces.  This is a property that
NO OPEN SOURCE PROJECT KNOWN TO ME has.  And it is a 
wonderful property to me as a blind programmer, because programs I write
in Emacs Lisp do usually run under X Windows, even if
I am not even technically able to test them under X.

So I'd really love to see the posibility to extend Emacs
Lisp with certain functions, which need code at the C level.

P.S.: The latest released version of the project I am talking about
can be found at http://delysid.org/gspi.html in case you are
wondering.

-- 
Thanks,
  Mario