On Sep 4, 2010, at 1:34 PM, Tobias C Rittweiler wrote:
In article 4818B0D6-5407-4B36-A2B7-1F50450DEA5F@in-progress.com, Terje Norderhaug terje@in-progress.com wrote:
On Aug 31, 2010, at 2:18 AM, Tobias C Rittweiler wrote:
In article 87pqx0kmga.fsf@desktop-ng.home.sw4me.com, Anton Kovalenko anton@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:
- 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:
- Emacs doesn't have to be configured to know the specific lisp syntax.
- Clojure, Scheme and other lisp dialects can be supported with no fuss.
- SLIME can handle custom reader macros with ease.
- 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@in-progress.com