[slime-devel] [investigation] Font lock, reader macros and SLIME repl

[Terje Norderhaug]

On Sep 4, 2010, at 1:34 PM, Tobias C Rittweiler wrote:
> In article <4818B0D6-5407-4B36-A2B7-1F50450DEA5F at in-progress.com>,
> Terje Norderhaug <terje at in-progress.com> wrote:
> 
>> On Aug 31, 2010, at 2:18 AM, Tobias C Rittweiler wrote:
>>> In article <87pqx0kmga.fsf at desktop-ng.home.sw4me.com>,
>>> Anton Kovalenko <anton at sw4me.com> wrote:
>>> 
>>>> Hello SLIME developers,
>>>> 
>>>> Both in the lisp-mode and in slime REPL, there is currently one major
>>>> thing that Emacs isn't getting right: constructs using reader macros
>>>> like #P"/home/" and #2A((1 0) (0 1)) are regarded as two sexps instead
>>>> of one. E.g. command for wrapping a sexp may turn #P"/home/" into
>>>> (#P)"/home/", etc. It gets even more awful with paredit-mode (that I
>>>> prefer to use), but the problem is noticeable even without it. 
>>>> 
>>>> I have investigated one possible solution to it, and here are the
>>>> results.
>> 
>> I recall we've discussed this issue in the past.
>> 
>> Rather than making emacs (as swank client) recognize the bounds of the lisp 
>> expression, swank could cover this functionality on the server. That is, 
>> emacs sends the expression to the swank server and gets back information 
>> about the boundaries of the expression. 
>> 
>> For example, in the case of a reader macro:
>> 
>> 1. Emacs streams the reader macro as characters to the swank server, 
>> continuing beyond the end of the expression.
>> 2. The swank server parses from the stream until the reader reaches the end 
>> of the expression.
>> 3. The server notifies emacs via swank how many characters were read when 
>> reaching the end of the expression.
>> 4. Emacs uses the information about how many characters were read to 
>> determine when the expression ended.
>> 
>> Using the inferior lisp to determine expression bounds has several benefits, 
>> including:
>> 
>> 1.  Emacs doesn't have to be configured to know the specific lisp syntax.
>> 2. Clojure, Scheme and other lisp dialects can be supported with no fuss.
>> 3. SLIME can handle custom reader macros with ease.
>> 4. No additional configuration required to cover custom reader macros.
> 
> You mean for every time I press C-M-f? Is that how your editor
> thingie works?

I am particularly concerned about lisp developers consistently being able to evaluate the current expression also when it contains reader macros and custom syntax (including other lisp dialects).

As to your question, like emacs, MCLIDE uses "rules of thumb" strategies to match balanced expressions. In fact, the lip editor of MCLIDE is a modernized version of good old Fred ("Fred Resembles Emacs Deliberately"), a Common Lisp implementation of relevant emacs lisp editor functionality. So C-M-f and other balance matching shortcuts in MCLIDE currently have similar shortcomings as emacs SLIME.


Terje Norderhaug
terje at in-progress.com