[slime-devel] Readtables
Terje Norderhaug
terje at in-progress.com
Mon Jan 4 05:22:32 UTC 2010
On Jan 2, 2010, at 9:33 AM, Seth Burleigh wrote:
> it would be great if slime included this!
Yes, this small change to the code would be very beneficial far
beyond the specific situation you brought up. It will provide better
support for evaluating "unconventional" expressions in the Listener,
such as custom reader macros, microlanguages, and other dialects of
Lisp such as Clojure. I am in favor of moving ahead with it asap.
-- Terje Norderhaug
terje at in-progress.com
> -----Original Message-----
> From: Terje Norderhaug [mailto:terje at in-progress.com]
> Sent: Friday, January 01, 2010 10:16 AM
> To: slime-devel at common-lisp.net
> Subject: Re: [slime-devel] Readtables
>
> On Jan 1, 2010, at 4:16 AM, Seth Burleigh wrote:
>> It doesn't appear to work when I use clisp.
>> When I define the macros like this
>> (set-macro-character #\[ (lambda (stream char) (read-delimited-list
>> #\] stream t)))
>> (set-macro-character #\] (get-macro-character #\)))
>>
>> And go [print
>> And then press enter it states 'error in process filter: wrong type
>> arguments: listp,0
>> Then when I press enter again it returns ; no value
>> Or I enter , say , 'a it'll return 'a.
>>
>> Im using the first code you posted.
>
> The code requires that SLIME implements the client side of the
> functionality.
>
> I have already implemented it for the MCLIDE client as proof of
> concept. Let me know if you want to try it out.
>
> I found it actually resulted in a simplification of the client code
> as the swank server takes the responsibility for determining the end
> of expressions in the listener.
>
> -- Terje
>
>> -----Original Message-----
>> From: Terje Norderhaug [mailto:terje at in-progress.com]
>> Sent: Thursday, December 31, 2009 11:47 PM
>> To: slime-devel at common-lisp.net
>> Subject: Re: [slime-devel] Readtables
>>
>> On Dec 31, 2009, at 9:23 PM, Terje Norderhaug wrote:
>>> On Dec 31, 2009, at 7:45 AM, Seth Burleigh wrote:
>>>> Is there any current support for having the REPL respect reader
>>>> macro characters? For example, if I define the [] pair to act like
>>>> parentheses the repl shouldn't automatically send a multiline [ ]
>>>> form to lisp until a matching ] has been found. On command line
>>>> REPLs, reader macro characters aren't evaluated until a matching ]
>>>> has been found.
>>>
>>> One way to have the REPL respect reader macro characters is by
>>> making
>>> evaluation on swank return the index of the first character not
>>> read,
>>> with the client using this as the starting position for the next
>>> read.
>>>
>>> Below is the minor required modification of swank.
>>
>> Here are the changes:
>>
>> diff -u slime-2009-12-31/swank.lisp slime-2009-12-31+/swank.lisp
>> --- slime-2009-12-31/swank.lisp 2009-12-23 00:15:03.000000000 -0800
>> +++ slime-2009-12-31+/swank.lisp 2009-12-31 21:43:45.000000000
>> -0800
>> @@ -2213,11 +2213,16 @@
>> (defun eval-region (string)
>> "Evaluate STRING.
>> Return the results of the last form as a list and as secondary
>> value the
>> -last form."
>> +last form, with third value indicating the index of the first
>> character not read in STRING"
>> (with-input-from-string (stream string)
>> (let (- values)
>> (loop
>> - (let ((form (read stream nil stream)))
>> + (let* ((index (file-position stream))
>> + (form (handler-case
>> + (read stream nil stream)
>> + (end-of-file ()
>> + (finish-output)
>> + (return (values values - index))))))
>> (when (eq form stream)
>> (finish-output)
>> (return (values values -)))
>> @@ -2293,12 +2298,13 @@
>> (with-retry-restart (:msg "Retry SLIME REPL evaluation
>> request.")
>> (track-package
>> (lambda ()
>> - (multiple-value-bind (values last-form) (eval-region
>> string)
>> + (multiple-value-bind (values last-form index) (eval-region
>> string)
>> (setq *** ** ** * * (car values)
>> /// // // / / values
>> +++ ++ ++ + + last-form)
>> - (funcall *send-repl-results-function* values))))))
>> - nil)
>> + (unless index
>> + (funcall *send-repl-results-function* values))
>> + index))))))
More information about the slime-devel
mailing list