I want to introduce the concept of buffer-readtables so C-c C-c and other commands will be able to process source strings with the right readtable being active.
For that, the :EMACS-REX event has to be adapted. At the moment, it looks as follows
(:emacs-rex rpc-sexp buffer-package buffer-thread cont-id)
My plan is to change it to
(:emacs-rex rpc-sexp cont-id buffer-context)
where buffer-context is a plist of form
(&key buffer-package buffer-thread &allow-other-keys)
so that a contrib can extend what constitutes a buffer-context.
Are you ok with this?
Or is it too general? Should I instead add just another parameter specifically for buffer-readtables?
-T.
* Tobias C. Rittweiler [2009-09-27 19:43+0200] writes:
I want to introduce the concept of buffer-readtables so C-c C-c and other commands will be able to process source strings with the right readtable being active.
First let me say that I have little sympathy for custom readtables. People who use custom syntax are fighting their tools.
For that, the :EMACS-REX event has to be adapted. At the moment, it looks as follows
(:emacs-rex rpc-sexp buffer-package buffer-thread cont-id)
My plan is to change it to
(:emacs-rex rpc-sexp cont-id buffer-context)
where buffer-context is a plist of form
(&key buffer-package buffer-thread &allow-other-keys)
so that a contrib can extend what constitutes a buffer-context.
Are you ok with this?
Well, no.
Or is it too general? Should I instead add just another parameter specifically for buffer-readtables?
I would prefer to fold the context arguments into the sexp and pass them down to the with-buffer-syntax macro. The thread is needed for dispatching and should stay easily accessible. Something like
(:emacs-rex sexp thread-id reply-id)
And a typical use would look like:
(defslimefun foo (some-string buffer-context) (with-buffer-syntax (buffer-context) ... (read-from-string some-string) ... ))
Helmut
Helmut Eller heller@common-lisp.net writes:
Or is it too general? Should I instead add just another parameter specifically for buffer-readtables?
I would prefer to fold the context arguments into the sexp and pass them down to the with-buffer-syntax macro.
Sure, I'll do it this way then. What is the reason that you prefer it?
-T.
* Tobias C. Rittweiler [2009-09-27 21:24+0200] writes:
Helmut Eller heller@common-lisp.net writes:
I would prefer to fold the context arguments into the sexp and pass them down to the with-buffer-syntax macro.
Sure, I'll do it this way then. What is the reason that you prefer it?
It feels cleaner to me. A general RPC server doesn't need to know about buffers. Not all RPCs need a buffer context, e.g. list-all-packages, but some like compile-string need the buffer filename and buffer position but it makes little sense to include that in every message.
For those RPCs which actually need buffer context (admittedly many) it's also not so bad to see the context as lexical argument. Certainly better than sending it twice as done currently for e.g. completion.
Helmut
Helmut Eller wrote, On 28/9/09 7:21 AM:
First let me say that I have little sympathy for custom readtables. People who use custom syntax are fighting their tools.
Can you say a little more about this? The only time I've used a custom readtable was when I was implementing a custom non-Lisp language for the application that was purpose-designed for the applications and its users, using a custom readtable and macros to translate the application language into s-expressions and then taking it from there in Lisp. One advantage was that user scripts could be compiled into fasls.
I didn't have a problem with the result, but I would like to hear the arguments for doing it a better way if I ever do something similar in the future.
-- sidney
* Sidney Markowitz [2009-09-27 22:13+0200] writes:
Helmut Eller wrote, On 28/9/09 7:21 AM:
First let me say that I have little sympathy for custom readtables. People who use custom syntax are fighting their tools.
Can you say a little more about this? The only time I've used a custom readtable was when I was implementing a custom non-Lisp language for the application that was purpose-designed for the applications and its users, using a custom readtable and macros to translate the application language into s-expressions and then taking it from there in Lisp. One advantage was that user scripts could be compiled into fasls.
I didn't have a problem with the result, but I would like to hear the arguments for doing it a better way if I ever do something similar in the future.
Typical problems with custom syntax:
- it's harder for the compiler to track source locations. Some compilers, e.g CCL, use the reader to mark source expressions with file positions. With custom readtables that's not done.
- many people forget about *read-suppress*
- the editor can't indent the code or it must be told how to do so
- the readtable is part of the compile-time environment and tools like ASDF must be told how to deal with it
- after a month of absence even the author has forgotten how the reader marco was supposed to work
Helmut
-
Helmut Eller -
Sidney Markowitz -
Tobias C. Rittweiler