From: Vladimir V. Zolotych
Subject: close-and-send-lisp
Date: 
Message-ID: <3A7D3A0A.348D9D87@eurocom.od.ua>
  Hello

When I try to evaluate the following form from ILISP source
buffer (via ILISP command close-and-send-lisp) 

(let ((buffer "\"a\" \"b\""))
  (loop initially (unless (char= (char buffer 0) #\") (loop-finish))
        for i of-type fixnum from 1 below (length (the string buffer)) 
        when (char= (char buffer i) #\") return i))

I get the error

Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable BUFFER is
unbound.

Also Emacs formats this form in a strange way.

All works if I use eval-region-and-go-lisp.

Using ILISP V5.10.1, Emacs 20.4.2, CMUCL 18c

This is minor inconvinience though.

-- 
Vladimir Zolotych                         ······@eurocom.od.ua

From: Marco Antoniotti
Subject: Re: close-and-send-lisp
Date: 
Message-ID: <y6chf2a4doz.fsf@octagon.mrl.nyu.edu>
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:

>   Hello
> 
> When I try to evaluate the following form from ILISP source
> buffer (via ILISP command close-and-send-lisp) 
> 
> (let ((buffer "\"a\" \"b\""))
>   (loop initially (unless (char= (char buffer 0) #\") (loop-finish))
>         for i of-type fixnum from 1 below (length (the string buffer)) 
>         when (char= (char buffer i) #\") return i))
> 
> I get the error
> 
> Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable BUFFER is
> unbound.
> 
> Also Emacs formats this form in a strange way.
> 
> All works if I use eval-region-and-go-lisp.
> 
> Using ILISP V5.10.1, Emacs 20.4.2, CMUCL 18c
> 
> This is minor inconvinience though.

I really do not know what may cause that.  I do not have time to
investigate and it is not clear to me what you are trying to do.  The
code works perfectly from the *cmulisp* buffer, i.e. the ILISP/CL
interaction buffer.

However, you'd get better responses by sending ILISP related questions
to the ILISP mailing list.

You can subscribe from the Sourceforge site

	http://www.sourceforge.net/projects/ilisp

Cheers

-- 
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group		 tel. +1 - 212 - 998 3488
719 Broadway 12th Floor                          fax  +1 - 212 - 995 4122
New York, NY 10003, USA				 http://galt.mrl.nyu.edu/valis
             Like DNA, such a language [Lisp] does not go out of style.
			      Paul Graham, ANSI Common Lisp
From: Vladimir V. Zolotych
Subject: Re: close-and-send-lisp
Date: 
Message-ID: <3A7D9598.6441F433@eurocom.od.ua>
Marco Antoniotti wrote:
> 
> ...  The
> code works perfectly from the *cmulisp* buffer, i.e. the ILISP/CL
> interaction buffer.

Yes, in *cmulisp* buffer. But not in source buffer where I can
send form to lisp via (close-and-send-lisp) command (C-]).

> 
> However, you'd get better responses by sending ILISP related questions
> to the ILISP mailing list.

Yes, but I don't know who is responsable for that (ILISP, Emacs).

Whould you mind tell me what is the reason for the
following error

Stack overflow in regexp matcher

This error appears sometimes when I press Space after
symbol in *cmulisp" buffer.


-- 
Vladimir Zolotych                         ······@eurocom.od.ua
From: Colin Walters
Subject: Re: close-and-send-lisp
Date: 
Message-ID: <877l36pa7u.church.of.emacs@meta.verbum.org>
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:

> Whould you mind tell me what is the reason for the
> following error
> 
> Stack overflow in regexp matcher
> 
> This error appears sometimes when I press Space after
> symbol in *cmulisp" buffer.

That's an Emacs error.  Try upgrading.
From: Hannu Koivisto
Subject: Re: close-and-send-lisp
Date: 
Message-ID: <8766iqoyu0.fsf@lynx.ionific.com>
Marco Antoniotti <·······@cs.nyu.edu> writes:

| "Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
| 
| >   Hello
| > 
| > When I try to evaluate the following form from ILISP source
| > buffer (via ILISP command close-and-send-lisp) 
| > 
| > (let ((buffer "\"a\" \"b\""))
| >   (loop initially (unless (char= (char buffer 0) #\") (loop-finish))
| >         for i of-type fixnum from 1 below (length (the string buffer)) 
| >         when (char= (char buffer i) #\") return i))
| > 
| > I get the error
| > 
| > Error in KERNEL::UNBOUND-SYMBOL-ERROR-HANDLER:  the variable BUFFER is
| > unbound.
| > 
| > Also Emacs formats this form in a strange way.
| > 
| > All works if I use eval-region-and-go-lisp.
| > 
| > Using ILISP V5.10.1, Emacs 20.4.2, CMUCL 18c
| > 
| > This is minor inconvinience though.
| 
| I really do not know what may cause that.  I do not have time to
| investigate and it is not clear to me what you are trying to do.  The
| code works perfectly from the *cmulisp* buffer, i.e. the ILISP/CL
| interaction buffer.

What probably happens is that, since close-and-send-lisp calls
reindent-lisp and it fucks up the indentation so that (char= ...)
form gets moved to the column 0, the send-lisp part of the function
sends just the (char= ...) form which refers to buffer which isn't
bound in that case.  I don't know why reindent-lisp doesn't work
for that code and when I quickly glanced at the code I decided that
I don't want to know :)  Perhaps I'll look into it again some day
when I'm really bored but in the meantime I send a copy of this
article to ILISP developers' list in the hope that someone more
adventurous would take a look at it a bit earlier.

"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:

| Marco Antoniotti wrote:
...
| > However, you'd get better responses by sending ILISP related questions
| > to the ILISP mailing list.
| 
| Yes, but I don't know who is responsable for that (ILISP, Emacs).

I'm not entirely sure I understand to what you are referring above.
In any case, ILISP isn't part of Emacs so ILISP-related questions
would be better off mailed to the ILISP mailing list, not to Emacs
newsgroups or c.l.l.

FWIW, as a workaround I'd suggest that you learn to use M-( and
M-).  With them you can keep your parentheses balanced at all times
so that you don't need the closing feature of C-] and can just use
M-C-x to evaluate the current form.

-- 
Hannu