Reported by Philipp Marek

Check for a zero-element character vector return from readChar.  (This
is not documented as the EOF return value, no, but it makes sense).

Also commit bug reports #18 and #19, and some README rearrangement.

Calculate the length of the output to emacs using nchar(type="bytes")

This makes help files sort-of work again

Allows slime-repl to start again.  I've said "utf-8-unix" but that is
almost certainly a lie; I have no real idea how R handles encodings of
text.  Simply passing in "ë" to the R slime repl breaks things without
too much effort.

This is important because e.g. the repl evaluation happens in the
global environment, so errors on code called from the repl will pull
up a backtrace with that evaluation frame, which can be inspected for
locals.  But printing out all the locals is a hugely expensive and not
helpful thing to do.

editing thinko: need tmp$value (not just value)

There ought to be some way of catching this mistake, which is passing
a non-length-1 vector to the swank functions, which then vectorise and
confuse the event stream.

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)

use new fancy :popup-buffer event in slime-media.

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

We've resolved and :FIXED: several.  Log a bug related to repl handling
of multiple expressions.

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

Should refactor (and provide width/height options)

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.

This time about visibility of evaluation results.

Allow ="foo"= to be exported as code.

for no better reason than my convenience

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.

1:£ crashes the swank connection (and is fairly easy to mistype when
demoing)

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