Oh boy.  I do not pretend to totally understand what is going on, but
what seemed to be happening is that somehow when walking the parse
tree to adjust srcrefs to the real file position rather than the
string position, the `empty' space in x[y,] was turning from a
zero-element name to a missing object, and then subsequent attempts to
evaluate the missing object (or even return it) were failing.

The workaround is to short-circuit the process for name objects, which
are atomic and (empirically) do not have srcrefs attached anyway and
so can be returned without modification.

actually return a list of two elements, not a bare string

Should try to find out how to have it loaded automatically

I don't yet know what's right, but it's fairly nonsensical to have
"[1] " prepending every label and value, so use prin1ToString

In the process, implement looking up foo$bar$baz, and passing those
completions back.  It's not completely robust to somewhat exotic
syntax, as it assumes that the text being completed can be used
directly as character vectors naming objects or fields; it is good
enough to get started, and now a lot less annoying to
use (particularly when lots of fields have underscores in them...)

Also note some other bugs as fixed.

Useful both for me, to track what slime version is most likely to be
maximally compatible, and for SLIMV users, which dispatch on the
version to know whether the protocol is byte-count-based or
character-count-based.

Now that slime-operator-at-point is overrideable, I can even test this
from within Emacs -- but thanks to Philipp Marek for implementing this
in his SLIMV-based environment first.

%in% needs a `vector' first argument, so make it so, listifying
anything that isn't already a vector.  (Note: there seem to be plenty
of non-vector first arguments that work, such as
as.Date("2012-01-01"), which returns FALSE to is.vector() -- but the new
code seems to get that right anyway, based on very limited testing.

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