public inbox for guile-emacs@sourceware.org
 help / color / mirror / Atom feed
From: Kalle Olavi Niemitalo <tosi@stekt.oulu.fi>
To: Keisuke Nishida <kxn30@po.cwru.edu>
Cc: guile-emacs@sourceware.cygnus.com
Subject: Re: Emacs Scheme interface
Date: Tue, 28 Mar 2000 23:06:00 -0000	[thread overview]
Message-ID: <87g0tavmox.fsf@PC486.Niemitalo.LAN> (raw)
In-Reply-To: <m3d7oft0gp.fsf@kei.cwru.edu>

Keisuke Nishida <kxn30@po.cwru.edu> writes:

> > (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.

But at least it is easy to grep for "lisp-eval" when there is a
better interface.  It is more difficult to convert from the
current ((point)) syntax.

> 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.

I wasn't actually thinking of GOOPS, just some unspecified
structure (a bare #<lisp-reference> could do) and procedures to
access it.

I don't have anything against GOOPS though :-)

> If (current-global-map) always returns a list, we can't do that.

Right, it should return some object through which the real keymap
can be modified.  This object can be a Lisp reference like now or
something specific to keymaps.

When importing a procedure, we should think of the value it
returns.  Numbers and strings should be copied.  Lists perhaps
too, if they are short and don't have to be modified in place.
Keymaps and strange objects like buffers can be Lisp references
for now; new Scheme types should be defined later.

I suppose things would be easier with Ken Raeburn's patches.  :-)

> Is that a convention among Guile applications?

Module naming has been discussed on the Guile list (I have
archives beginning from Feb 1999), but I don't think there was a
conclusion.

> omitting `app' will not hurt anyone.

True, nobody else is going to have a top-level `emacs' package.

> Have you tried Guile's multithread supoprt with Guile Emacs?

I haven't.

  parent reply	other threads:[~2000-03-28 23:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-03-27 22:51 Keisuke Nishida
2000-03-28  4:01 ` Kalle Olavi Niemitalo
2000-03-28 10:27   ` Keisuke Nishida
2000-03-28 11:37     ` Ken Raeburn
2000-03-28 23:06     ` Kalle Olavi Niemitalo [this message]
2000-03-29 16:57       ` Keisuke Nishida
2000-03-28 11:43 ` Kalle Olavi Niemitalo
2000-03-28 12:23   ` Keisuke Nishida
2000-03-29  2:33     ` Kalle Olavi Niemitalo
2000-03-29 17:09       ` Keisuke Nishida
2000-04-30 12:08         ` Kalle Olavi Niemitalo
2000-03-31 17:48 ` Keisuke Nishida
2000-03-31 22:42   ` Klaus Schilling
2000-04-01  9:02     ` Keisuke Nishida

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=87g0tavmox.fsf@PC486.Niemitalo.LAN \
    --to=tosi@stekt.oulu.fi \
    --cc=guile-emacs@sourceware.cygnus.com \
    --cc=kxn30@po.cwru.edu \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).