Re: [O] R code block produces only partial output

[Charles C. Berry]

On Tue, 5 Aug 2014, Aaron Ecay wrote:

> Hi Chuck,
>
> 2014ko abuztuak 5an, "Charles C. Berry"-ek idatzi zuen:
>
> [...]
>
> > Here is the docstring from ESS's inferior-S-prompt:
> >
> > inferior-S-prompt is a variable defined in `ess-custom.el'.
> > Its value is "[]a-zA-Z0-9.[]*\\([>+.] \\)*> "
[snip]
> > ----
> >
> > Note that there is a space *required* after the [>+.], but the hard coded
> > regex in `org-babel-R-evaluate-session' lets the space be optional.
> >
> > I am guessing the a-zA-Z stuff is there to strip 'Browse[1]> ' prompts and
> > such, which probably isn't an issue for babel.
>
> Why doesn’t org just use the value of inferior-S-prompt?  (which would
> then need to have the bit concatenated to the end that matches
> e.g. [1]).  Another way of putting this might be “does the space that
> ESS requires ever turn up missing?”

I don't really know why.

Re the space, do the characters preceeding the [>+.] ever show up 
in Babel output?

> > Just before the defcustom for inferior-S-prompt, I see this comment
> > in ess-custom.el:
> >
> > ;; need to recognise  + + + > > >
> > ;; and "+ . + " in tracebug prompt
> >
> > Ha! The '.' seems to be for ess-tracebug. I am guessing that nobody will
> > need to output tracebug sessions from babel. So maybe it is safe to delete
> > the "." after all - or at least require the space after it.
>
> Tracebug is on by default in ESS – C-h v ess-use-tracebug.  Tracebug
> even has babel support: see e.g. line 148 in ess.tracebug.el
> <https://github.com/emacs-ess/ESS/blob/4283f1304a54502c42707b6a4ba347703f0992dd/lisp/ess-tracebug.el#L148>.

When I said 'output tracebug sessions' I meant in the sense of using 
`:results output' to save the part of the session pertaining to tracebug 
in the *.org buffer, which seemed like an unusual use case.


> > Maybe the regex should be put in a defcustom.
>
> Why?

options(prompt="$ ") # for example

Plus, if anything like the case that started this thread ever happens 
again it might be easier to figure out and offer workarounds for special 
cases that would be hazardous as a default setting.

> The current mismatch between babel and ESS seems like a bug, but
> once that’s fixed I don’t see the use case for configurability here.
> (But maybe you have something in mind...)

It looks like the babel regex was copied and intentionally modified for 
some reason --- suggesting the author knows something we do not, e.g. a 
case that would be broken by using `inferior-S-prompt'.

I don't have a handle on all the issues in `comint-use-prompt-regexp' and 
all the `inferior-*-prompt' variables, but those are customizable.

If the mismatch is a bug, why not use 'inferior-S-prompt' as the default 
and allow customization or at least use  `(defvar org-babel-R-prompt 
inferior-S-prompt)'?

HTH,

Chuck