support ?help buffers

[swankr.git] / BUGS.org

diff --git a/BUGS.org b/BUGS.org
index bad55e6d4c684fb6f74d0b3a63c8f8e412711662..24cd075174228f79450ef6e0402050bbfdc12323 100644 (file)
--- a/BUGS.org
+++ b/BUGS.org
@@ -3,18 +3,48 @@
 #+AUTHOR: Christophe Rhodes
 #+EMAIL: csr21@cantab.net
 #+OPTIONS: H:0 toc:nil
 #+AUTHOR: Christophe Rhodes
 #+EMAIL: csr21@cantab.net
 #+OPTIONS: H:0 toc:nil

-* OPEN #1 printed output not redirected to slime repl
+* RESOLVED #1 printed output not redirected to slime repl       :MINOR:FIXED:

   The output from functions performing printing is sent to the
   standard output of the process running =swank()=, not to an emacs
   stream.
   The output from functions performing printing is sent to the
   standard output of the process running =swank()=, not to an emacs
   stream.

-* OPEN #2 popping beyond inspector history crashes
+* OPEN #2 popping beyond inspector history crashes                   :NORMAL:

   Inspecting something and hitting =l= causes the R debugger to pop
   up from trying to send =NULL= in a sexp to Emacs.
   Inspecting something and hitting =l= causes the R debugger to pop
   up from trying to send =NULL= in a sexp to Emacs.

-* OPEN #3 source reference in compile-string-for-emacs
+* RESOLVED #3 source reference in compile-string-for-emacs   :WISHLIST:FIXED:

   It would be good if we could associate the expressions in the string
   with a reference to the corresponding source.  Unfortunately, emacs
   only passes the buffer position in bytes (or maybe characters),
   whereas R's srcrefs work with lines and columns.
   It would be good if we could associate the expressions in the string
   with a reference to the corresponding source.  Unfortunately, emacs
   only passes the buffer position in bytes (or maybe characters),
   whereas R's srcrefs work with lines and columns.

+* OPEN #4 multibyte characters corrupt slime connection              :NORMAL:
+  Not in all circumstances (e.g. ="£"= is OK) but =1:£= fails in
+  slime-net-read-or-lose.
+* RESOLVED #5 respect visibility of evaluated results        :WISHLIST:FIXED:
+  I think we can do this by calling =.Internal(eval.with.vis(...))=
+  instead of just regular =eval()=
+* OPEN #6 occasional invalid sink() errors                           :NORMAL:
+  Not sure yet when it happens, but it makes the terminal browser pop up.
+* OPEN #7 swank server is uninterruptible                            :NORMAL:
+  at least in certain conditions
+* RESOLVED #8 startup is not filesystem-location independent    :MINOR:FIXED:
+  Requires the cwd to be the swankr directory to be able to find
+  swank-presentations and swank-media
+* RESOLVED #9 help and ? to produce help buffers             :WISHLIST:FIXED:
+  Not like ESS, though: that works by looking at the user's input with
+  a regexp.  Use slime-media?
+* RESOLVED #10 0 or more than 1 exprs at REPL                   :MINOR:FIXED:
+  Entering 0 exprs (whitespace or the empty string) at the REPL gives
+  an error from `swank:listener-eval`, which subscripts the parse tree
+  with index 1.  (Entering more than one simply ignores all after the
+  first, assuming that they all parse).  We should be a bit more like
+  R's repl, evaluating each of the exprs in turn and treating the
+  results a bit like CL's multiple values
+* OPEN #11 no newline when using :popup-buffer for ?help              :MINOR:
+  Logged here so that I don't forget it if I sort out #9 first: we
+  need to be able to indicate "no repl result please" if we open a new
+  temporary buffer to display the result.
+* OPEN #12 need to be more careful when searching for completions    :NORMAL:
+  Gets thoroughly confused on completing "read." because the "." is
+  treated as a regexp "any character" pattern.

 * COMMENT:
 Local Variables:
 mode: org;
 * COMMENT:
 Local Variables:
 mode: org;