Given that source block a user would see the result
#+RESULTS:
: 2
:
:
:
: 212
whereas something like
#+RESULTS:
: 2
: 212
would be expected.
ob-julia is mainly based on ob-R. It looks as if inferior-ess-send-input works differently for Julia and R sessions in ESS. Specifically, in ob-R the result of evaluation is essentially one string containing the desired output. In ob-julia the result is one string per source block line (including "\n" for each comment line). These strings get concatenated to the final result containing all those newlines. The approach taken here is to replace excessive (i.e. three) consecutive newline characters with an appropriate number of newlines (i.e. one) in the resulting output string.
This does not feel like the correct fix, more like a workaround, but works without getting into different ESS session evaluation specifics. Please let me know if you can think of a better way.
This is a tentative fix for #8. It was tested with the code block
i.e. running with a session and taking the output as evaluation results - which is a workaround for #9 as seen in https://github.com/gjkerns/ob-julia/issues/9#issuecomment-394425112.
Given that source block a user would see the result
whereas something like
would be expected.
ob-julia
is mainly based onob-R
. It looks as ifinferior-ess-send-input
works differently for Julia and R sessions in ESS. Specifically, inob-R
the result of evaluation is essentially one string containing the desired output. Inob-julia
the result is one string per source block line (including "\n" for each comment line). These strings get concatenated to the final result containing all those newlines. The approach taken here is to replace excessive (i.e. three) consecutive newline characters with an appropriate number of newlines (i.e. one) in the resulting output string.This does not feel like the correct fix, more like a workaround, but works without getting into different ESS session evaluation specifics. Please let me know if you can think of a better way.