> This little detail will likely end up forcing the Elisp side to either > re-implement a sexp-reader by hand (in Elisp, which will be slowish), > or require ugly hacks to try and pre-process the answer before passing > it to the sexp reader (or post-process the sexp), which will likely > always end up flaky.
I would just like to remark that the focus of SerAPI is that when some friction arises between the client and the server, it should always be SerAPI the one to make the effort to adapt so life of the client is easier. I think I like this approach for 2 reasons: - clients have already an enough hard time dealing with display, the user, etc... more complexity in the clients is not good, and for sure clients are going to be more constrained, - in this case SerAPI has both full control and synchronous access to the prover, so it has a much better time implementing any kind of klugde. Cheers, E. _______________________________________________ ProofGeneral-devel mailing list ProofGeneral-devel@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/proofgeneral-devel
