On 2017-02-27 10:17, "Charles C. Berry" writes:
> IMHO, it is often best to handle formatting of output in the language of
> the src block. There are some tools for doing this in R: the `ascii'
> package is one. `xtable' is another.
I've had the same problem when working with tables and ocaml
Yes, it is a rare case indeed. It's not necessary nor appropiate to
change Babel's behavior.
Long story short, I'm building several LaTeX tables from CSV files
which in turn come from Excel files. I'm not the author of these Excel
files and I have to reproduce them as faithful as possible.
The pr
On Mon, 27 Feb 2017, Vicente Vera wrote:
Hello again, I'm sorry for being noisy.
OK yes, `org-babel-read' is indeed converting "number strings" to
numbers.
[proposed fix deleted]
I don't have a feeling as to whether the proposed fix is appropriate.
However, there are other ways to solve th
Hello,
Vicente Vera writes:
> It would be useful to have a header argument to prevent this
> conversion. Probably somebody else has had the same issue?
Since this case may be rare, what about inserting a non breaking
zero-width space right before 3.350?
Regards,
--
Nicolas Goaziou
Hello again, I'm sorry for being noisy.
OK yes, `org-babel-read' is indeed converting "number strings" to
numbers.
Basically this is what happens:
: (string-to-number "3.350") => 3.35
To leave cell values unchanged I did this clumsy hack:
#+BEGIN_SRC emacs-lisp
(defun test-other-org-babel-re
Probably the issue is related to this function in `ob-core.el'?
org-babel-read: "Convert the string value of CELL to a number if
appropriate."
Behind the curtains lies the built-in function `string-to-number'.
Maybe that conversion should be made optional to leave the strings
untouched.
2017-02
