[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs+guile

From: Ken Raeburn
Subject: Re: emacs+guile
Date: Tue, 3 Jan 2006 17:09:47 -0500

On Jan 3, 2006, at 11:10, Mikael Djurfeldt wrote:
Emacs behavior is to a large extent controlled by the state of a set
of global and buffer-local variables. Elisp code often uses dynamic
binding to temporarily change some state, such as:

Yep. Especially when (if?) it comes to a multithreaded Emacs, handling dynamic bindings is going to be a huge issue. As for the primitives looking at those variables, that's an angle I hadn't thought much about.

I'm still not entirely convinced by the "Lisp and Scheme should just magically interoperate seamlessly" camp. (Okay, maybe I'm misrepresenting the position a little.) So if we need one function to provide a Lisp-y interface and another to provide a Scheme-y interface, presumably with one capable of being a wrapper around the other, I don't think it would bother me too much. But I can't even share symbols between the two languages yet, even to the point of code in one language being able to see symbols in the other language, much less see them as native symbols. So I guess there's a little time to figure that out. Or for the Scheme experts to point me in the right direction. :-)

As you mention, it does seem like fluids would offer a way to deal with Lisp dynamic binding issues. Buffer- and frame-local variables bother me more. They make the variable bindings dependent on bits of external state, but buffers and frames probably shouldn't be the relevant concepts down at the basic Scheme level, it should be something more generic. Hmm... did we go over this a few years ago? I vaguely recall a suggestion of using a procedure-with-setter for a Lisp variable, invoking it to get the value, which could go off and check for buffer-local settings etc. Not sure how that would interact with dynamic bindings (or, offhand, how it's supposed to interact). I should go dig through the archives sometime....

 (let ((case-fold-search nil)))
    (string-match ...))

New primitive, with no Lisp variable references:
(string-match-1 regexp string &optional start case-fold)
(defun string-match (regexp string &optional start)
  (string-match-1 regexp string start case-fold-search))
Or something...

Possibly one could indeed use fluids if enough convenient helper
syntax, such as some variant of fluid-let, is provided. Personally,
I've been playing with the thought of storing state, such as
case-fold-search, in some kind of objects representing context in
similarity to how GWM (The Generic Window Manager) handles properties
of X windows. Also in this case, there is a need of helper syntax. The
advantage would be that one could avoid dynamic binding and have a
somewhat better modularization and abstraction of states.

I'm not familiar with GWM, though it sounds like stuff I'm doing at work. Sounds like a good approach.

Third-party Lisp code still has to continue to work, so to Lisp code, it has to look like dynamic binding of case-fold-search does the right thing; so, either the dynamic binding of case-fold-search or the execution of string-match from Lisp still needs to make the right thing happen.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]