and also `swank:describe-definition-for-emacs`, helping to make it useful. It's still a bit weird with the confusion between name of thing, name of help file, and so on (and also because describe-definition-for-emacs must return a definition kind from a restricted set defined in base slime) but it's basically working.
For better presentations
from Philipp Marek, about an eternity ago.
I do not pretend to understand whether this is new, but in 2.14 parsing an expression, in addition to adding srcref attributes to the results of the parse, can result in actual srcref elements being in the results. Those srcrefs also need to be frobbed so that display of functions at the repl works properly. (I do think this worked in 2.12 without this extra frobbing, but I am totally prepared to admit that I can't really remember). Since we're on the case, also frob things that look like srcrefs but aren't under "srcref" attributes, such as "wholeSrcref"s
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.
Should try to find out how to have it loaded automatically
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...)
%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.
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.
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)