This is the mail archive of the guile-emacs@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Emacs Scheme interface


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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]