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

[Andreas Kiermeier]

Hi Aaron,

thanks for keeping on this.

I personally don't have a problem with requiring an R package.

In fact, users will have a rather limited experience with R if they cannot install add-on packages (for whatever reason) - this is one of the things that makes R such an attractive option for data analysis.

While there might be some IT departments that are very restrictive, I also think (no data behind this) that the majority of our users are not in that situation.

Anyway, that's my two cents worth.

​Cheers,

Andreas

On 23 August 2014 18:02, Aaron Ecay <address@hidden> wrote:

2014ko abuztuak 19an, Achim Gratz-ek idatzi zuen:

>
> Aaron Ecay writes:
>> R is capable of installing packages to a user-specified directory,
>> without requiring root or any other special privileges.  So IT cannot
>> literally prevent R users from installing their own packages;
>
> They can, all they have to do is to take away the ability to connect to
> the outside network and that's what is increasingly being done (for
> other reasons, mind you).
>
>> the requirement must rather come as a statement of policy.
>
> That is another common thing, if only to shift the responsibility if the
> other measures don't actually prevent that.
>
>> I’d like to
>> understand more about how such regimes work and how org could work
>> with them, ideally from people who have direct experience with them.
>
> Ideally, don't require the use of a non-core package.  The beef with
> things like CTAN, CRAN or CPAN is that they require extra maintenance
> beyond the pure installation of some software and some specific
> knowledge of the software in question and that's just not going to
> happen in some places.
>
>> Otherwise, it would be disappointing if the fear that an unidentifiable
>> somebody somewhere might not be able to install R packages derailed the
>> improvement of babel’s R support.
>
> The request was to keep a fallback to core.  I have no comment at this
> time if it would be possible or not.  Since ultimately it's the session
> support of Emacs that is clunky (and that affects most other languages
> as well), maybe an effort to improve that would be more generally
> helpful than working around it in different ways in each language.

Well, I think that it’s going to be difficult to make babel a better
literate programming solution for R if we restrict ourselves not to
use the state-of-the-art R package for low-level literate programming
support.  Org is full of features which one needs to install other
software to use, and I’m comfortable with the idea that babel’s R
support should require the evaluate package.  However, it’s difficult
to argue this point of view when no one has spoken up about their own
requirements, and a spirit of conservatism in the face of vague
imagined difficulties persists.

The attached patch fixes the problem that touched off this thread.
It’s only debatably nicer than the present approach, but it has the
independently desirable property of segregating babel-driven output
from the session buffer.  It incorporates what I think is a fix for
the tramp bug Charles pointed out.

It’s as yet only lightly tested, and as always comments are welcome.

--
Aaron Ecay