emacs+guile

emacs+guile

[Ken Raeburn]

Some of you may remember the guile-emacs project I started on years  
ago.  I let it slide a bit when other things got in the way, but the  
last year or so I've been putting some work into it again.

I've got a source tree tracking the Emacs CVS sources which can be  
configured to use Guile for the basic object representation, some of  
the allocation, etc.  It's got a simple Scheme evaluation mode, too,  
which shouldn't be hard to enhance a bit.  ("ism" looks remarkably  
similar to "ielm"....)  Lisp and Scheme can't really talk to each  
other very well yet, though.

The Guile library is not unexec-friendly, so this version has to have  
the unexec part of the Emacs build disabled.  There are some glaring  
but probably not difficult problems which I think may derive largely  
from this (non-tty startup doesn't work; "make bootstrap" doesn't  
work), but I'm working on them.  In a terminal frame, the basics seem  
to work -- I can run dired and shell mode, and font-lock mode colors  
a C source file on a color xterm.  I haven't stress-tested it, and  
probably won't until I get X and/or Carbon display working, but at  
the moment, while I know of a few things that don't work, and a lot  
of Scheme-Lisp-interface type things people might eventually want  
that aren't there yet, I'm currently not aware of any other serious  
problems.  Well, as long as you don't count the code quality in a few  
places... :-)

If you'd like to play with it, see http://www.mit.edu/~raeburn/ 
guilemacs/ -- the current state is described there, and there's a  
link to source to download.  (No public repository at the moment,  
sorry.)  Let me know what you think, send patches, etc.

Ken


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: emacs+guile

[William Xu]

Ken Raeburn <raeburn@raeburn.org> writes:

> Some of you may remember the guile-emacs project I started on years
> ago.  I let it slide a bit when other things got in the way, but the
> last year or so I've been putting some work into it again.

[...]

Great ! i'd really love to have a scheme-emacs.

-- 
William


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: emacs+guile

[Per Bothner]

William Xu wrote:
> Ken Raeburn <raeburn@raeburn.org> writes:
> 
> 
>>Some of you may remember the guile-emacs project I started on years
>>ago.  I let it slide a bit when other things got in the way, but the
>>last year or so I've been putting some work into it again.
> 
> 
> [...]
> 
> Great ! i'd really love to have a scheme-emacs.

You might find JEmacs (http://jemacs.sf.net) interesting.
It's different and more radical approach than Ken's.  It is also
a very unfinished, because nobody is spending much time on it.

JEmacs is part of the multi-languge Kawa environment
(http://www.gnu.org/sofwtare/kawa/).  Both Scheme and Emacs Lisp
(and other languages) can co-exist, and both can be compiled to
Java bytecodes.  JEmacs can use multiple GUI backends, currently
Swing and SWT.

Unfortuntely, neither I nor anyone else is spending much time on
JEmacs, so it's never gotten to the "actually usable" stage, and
there is probably some "bit-rotting".  However, I have started doing
some *very* interesting GUI programming with Kawa, which looks like
it will also benefit JEmacs.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: emacs+guile

[Mikael Djurfeldt]

On 1/3/06, Ken Raeburn <raeburn@raeburn.org> wrote:
> Some of you may remember the guile-emacs project I started on years
> ago.  I let it slide a bit when other things got in the way, but the
> last year or so I've been putting some work into it again.

That is good news!

However, concerning moving from Elisp to Scheme, there is one usage
pattern in Elisp code which I think does not yet have any good
counterpart on the Scheme side:

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:

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

Yes, lexical binding is cleaner and safer, and/or/but, yes, Scheme can
provide dynamic binding using fluids, but the thing is that, given the
extensive use of the above usage pattern in Emacs code I think we have
to come up with some alternative which is as elegant and simple to
use.

If we don't, I expect that this will become the single largest
obstacle for gaining a broad acceptance of Scheme in the Emacs
community.

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.

M


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: emacs+guile

[Per Bothner]

Mikael Djurfeldt wrote:
> However, concerning moving from Elisp to Scheme, there is one usage
> pattern in Elisp code which I think does not yet have any good
> counterpart on the Scheme side:
> 
> 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:
> 
>  (let ((case-fold-search nil)))
>     (string-match ...))
>
> 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.

Fluid-let or SRFI-39 "parameter objects" seems to work pretty well.
Kawa provides both: a "fluid variable" is loosely a named alias
for a parameter object.  However, there are some complications if
you want to support multiple threads (or futures) and have bindings
be inherited from a parent thread to a child thread.
See http://www.gnu.org/software/kawa/Parameter-objects.html
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: emacs+guile

[Ken Raeburn]

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)
Lisp:
(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.

Ken


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user