From: Mario Lang <mlang@delysid.org>
Subject: A plea for dynamically loadable extension modules
Date: Wed, 30 Jul 2003 14:16:01 +0200 [thread overview]
Message-ID: <87wue0i51a.fsf@lexx.delysid.org> (raw)
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
next reply other threads:[~2003-07-30 12:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-30 12:16 Mario Lang [this message]
2003-07-30 12:42 ` A plea for dynamically loadable extension modules Nic
2003-07-30 13:13 ` Kenichi Handa
2003-08-01 2:20 ` Richard Stallman
2003-07-30 13:43 ` Mario Lang
2003-07-30 14:24 ` Jason Rumney
2003-07-30 14:40 ` Mario Lang
2003-07-30 15:25 ` Paul Jarc
2003-08-01 2:20 ` Richard Stallman
2003-08-01 15:44 ` Paul Jarc
2003-08-04 0:08 ` Richard Stallman
2003-07-30 19:02 ` Kevin Rodgers
2007-08-17 21:30 ` Leo
2007-08-19 0:45 ` Richard Stallman
2007-08-19 1:33 ` Leo
2007-08-19 3:22 ` dhruva
2007-08-19 7:59 ` Stephen J. Turnbull
2007-08-19 12:51 ` Thien-Thi Nguyen
2007-08-19 13:06 ` David Hansen
2007-08-19 22:30 ` Richard Stallman
2007-08-19 22:31 ` Richard Stallman
2003-07-31 4:10 ` Stephen J. Turnbull
2003-07-31 7:56 ` David Kastrup
2003-07-31 9:59 ` Stephen J. Turnbull
2003-07-31 18:57 ` Alex Schroeder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wue0i51a.fsf@lexx.delysid.org \
--to=mlang@delysid.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.