I can verify that the :post work-around suggested by Chuck and implemented by Jeremie works as advertised.
FWIW, I would certainly prefer to see the implementation org-babel-R-write-object-command changed so that the work-around wouldn't be necessary. Thank you to both Chuck and Jeremie for looking into this. Jeremie Juste <jeremieju...@gmail.com> writes: > [External Email] > > Hello, > > Thanks for the feedback > > || On Saturday, 16 Jan 2021 at 00:19, Berry, Charles" via "General > discussions about Org-mode. wrote: >> You can use a :post header to customize outputs like this to make them >> more pleasing. Or just use your own >> `org-babel-R-write-object-command'. > > > As a quick work around you can use > > #+name: remove-nil > #+begin_src emacs-lisp :var tbl="" > (mapcar (lambda (row) > (mapcar (lambda (cell) > (if (equal "nil" cell) > "" > cell)) > row)) > tbl) > > #+end_src > > > > #+BEGIN_SRC R :results value :colnames yes :post remove-nil[:colnames > yes](*this*) > data.frame(A=c(NA,1,1,1,1),B=c(1,2,NA,4,4)) > #+end_src > > #+RESULTS: > | A | B | > |---+---| > | | 1 | > | 1 | 2 | > | 1 | | > | 1 | 4 | > | 1 | 4 | > > > >>> Probably a silly question, but in ob-R.el, what is the reason for >>> setting na=\"nil\" when defining org-babel-R-write-object-command? Is >>> this an elisp compatibility thing? >>> >> >> I don't get it either. The value corresponding to the NA becomes a string in >> emacs-lisp whether \"nil\" or \"\" is used. >> So when passed to elisp via a :post header referencing an emacs-lisp >> src block, its treated as a string. > > Thanks Chuck for pointing this out. R users are used to handle NA but in > this particular case where empty string and NA are treated > the same, I'm not sure the nil feature is very useful. If it does not break > anything else I will consider removing it. > > > Best regards,
