This is the mail archive of the
guile-emacs@sourceware.cygnus.com
mailing list for the Guile project.
Re: Emacs Scheme interface
- To: Kalle Olavi Niemitalo <tosi at ees2 dot oulu dot fi>
- Subject: Re: Emacs Scheme interface
- From: Keisuke Nishida <kxn30 at po dot cwru dot edu>
- Date: 28 Mar 2000 13:26:46 -0500
- Cc: guile-emacs at sourceware dot cygnus dot com
- References: <m3ln33ege5.fsf@kei.cwru.edu> <87n1njuww0.fsf@PC486.Niemitalo.LAN>
Kalle Olavi Niemitalo <tosi@ees2.oulu.fi> writes:
> If a Lisp reference is needed, one can call
> (lisp-eval '(current-global-map)).
I don't think it is a good interface. It is harder to understand and
may not work in the future.
I think a better way to get around this is to define a GOOPS class
for keymaps and define suitable procedures which call Lisp functions
appropriately as you may think in your mind. If (current-global-map)
always returns a list, we can't do that.
> IIRC, SCWM keeps its modules under (app scwm ...). Perhaps Emacs
> modules should be (app emacs ...).
Is that a convention among Guile applications? If there is no such
convention yet, we should talk to the Guile team. In my opinion,
such a declaration like (use-modules (app emacs majormode scheme))
is a little bit long... An Guile application often adds its own
primitives (e.g., lisp-eval) and the scheme programs does not work
with other applications, which means the scheme programs should be
installed separately from Guile's shared directory, so omitting
`app' will not hurt anyone.
> I would really like thread support in Emacs Scheme. Multiple
> threads should be able to process different buffers at the same
> time. Perhaps the "current buffer" should be thread-local.
Me too, but as long as we use the current Lisp functions, it may be
hard to work around... Have you tried Guile's multithread supoprt
with Guile Emacs? Does it work well?