tryCatch is R's handler-case.  (Spent some time wondering why
withCallingHandlers wasn't working, but that's handler-bind.)

otherwise extended regexp metacharacters, particularly ".", get
interpreted as those metacharacters rather than literals.  (bug #12)

It's easy really; just iterate over expressions.  Resolves bug #10.

Makes C-c C-r substantially less painful, and also produces slightly
fewer surprises at the REPL.  (resolves #5)

depends on swank.R itself being source()d with chdir=TRUE, but doesn't
break any previously-working use case.

There's a race condition, I think, in between writing the socket port
and running the socket server; it might be as simple as reordering the
writing and the socket opening, but strange things happened once when
I did that.

Because of our vaguely dodgy heuristic for finding the "defun" to
evaluate, C-c C-c is not terribly useful.  This allows at least C-c
C-r to be used without thinking.

also retain source information in swank:load-file for maximum emacs
goodness.

Parse them into TRUE and FALSE in the lisp->R translator

This fixes bug #1.  It is somewhat on the risky side given that there
are current known protocol problems in the presence of non-ASCII
encodings, but it does make working in the slime repl much more
pleasant.

Wow, this was hard.  parse() constructs a vector with mode
"expression", consisting of multiple, possibly nested calls.
Scattered throughout this structure are srcrefs with absolute
locations.  This means that we need to walk the parsed data structure
and adjust every srcref that we can find, giving it an offset based on
the location information passed to compile-string-for-emacs (which
requires bleeding-edge 2010-10-08 slime, because earlier versions
don't pass line/column information in the position argument).

But we can't simply adjust the "srcref" attribute on our parsed data
structure, because R tries very hard to be pure.  Instead we need to
return a copy with the right modifications (but preserving everything
else of importance).  It's straightforward once you know how, but
there were many painful missteps to get to this point.  Still, now
M-. works on function names assigned with C-c C-c in source buffers.

In particular, include enough of a kludge to be able to handle both
relative and absolute paths.

Firstly, only parse, don't source, as that seems to be the
protocol (the emacs side is responsible for requesting a load if
desired).  Secondly, the protocol is also to return a
compilation-result structure rather than just TRUE, so do that too.

Easy, peasy.  The only trick here is to use parse() in the case that
compile-file-for-emacs is not being asked to load the `compiled' file.

It was surprisingly hard to intuit getwd() and setwd(), what with
apropos("dir") and apropos("cwd") failing.  Nevertheless, they exist
and function, so use them for the interface (but not slimefun)
functions.

R has capture.output as equivalent to with-output-to-string, so use it.

printToString, used by the slime-repl, now reverts back to calling
print.  New function prin1ToString, used by swank:interactive-eval and
swank:eval-and-grab-output, uses deparse.

default makeReplResult function doing the standard
(:write-string value :repl-result) thing for the REPL.

Reified environments make quite a lot of this fairly easy...

Stands a chance of making the inspector not utterly annoying

It took me quite some time to remember that parse returns a list of
expressions rather than just a single expression...

Wow, nearly working.  There's some way of causing R to get into the
proper debugger; not sure how to reproduce it yet.

Use an environment for istate rather than a list

implement swank:inspector-nth-part and swank:inspect-nth-part

Implement enough that C-c I begins to work, at least for values like
list(1,2,3).  The resulting inspector on the emacs side apparently has
no features, and an error message results on quitting the inspector
because I've only implemented `swank:init-inspector`, and not
`swank:quit-inspector`.  Still, good enough to checkpoint.

Use it in swank:interactive-eval and swank:eval-and-grab-output

Possibly, anyway.  I think the semantics are right.  Use it in
printToString and in swank:eval-and-grab-output.

These are (in principle, at least) really, really easy.

instead of using print(), use str().  Also, be even more cautious
about cleaning up in printToString; previously, errors in printing
would lead to a sink to a closed fifo...

Printing is still not really right, and I forsee that we will end up
writing our own printer to get something more lispy.  But at least
this approach tends not to dump huge tables into the REPL.

in readPacket, call socketSelect() before actually trying to read on
the connection.  This seems to allow R to update graphics windows and
other such niceties.

It would be nice to be able to preserve the (inferior) R REPL as well,
but I haven't yet discovered whether that's possible.

A simple implementation, only looking for a single function
definition (no methods, whether S3 or S4, or indeed anything else).
Enough to support M-., though.

it worked before while emacs and R were started with the same working
directory; this is not always going to be the case.

There's a lot here that's ugly, unfinished or just downright horrible.
Most notably, presentation support depends on swank-side read-time
evaluation (indicated with Common Lisp syntax, which hilariously is a
comment in R).  We can't support that in general, but we can
special-case the presentation-specific operator.

But then the next difficulty comes along; actually performing that
read-time evaluation needs to happen in a different environment than
the evaluation of the REPL form.  In order to achieve this, we abuse
bquote() the equivalent of Lisp's backquote facility, by calling what
in CL terms would be its macro-function on the parsed, preprocessed
expression; only after doing that (and hence resolving the `read-time'
evaluations) do we evaluate the call itself.

The implementation of presentation protocol messages is also slightly
ugly; having to implement cl:nth-value is particulraly horrible, but
the lack of weak references / weak tables in R (at least as far as I
can tell at the moment) is a cause of niggling concern.

We can do this nicely now that we have an evaluator of :emacs-rex
forms that can cope with quote.

This is all a bit horrible, but probably limited in maintenance headaches.

don't return (:ok (:values "string")); instead, send a separate
(:write-string "string" :repl-result) and return (:ok ())