Re: na=\"nil\" in ob-R.elo
Hello,
Thanks again for reporting this. With the attached patch I'll remove
nil replacement for NA.
>From 90881079d431a8af3cba5be14ecf882735ed7a6a Mon Sep 17 00:00:00 2001
From: Jeremie Juste
Date: Sat, 6 Feb 2021 20:50:00 +0100
Subject: [PATCH] For :results value, return empty string instead of nil
---
lisp/ob-R.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index f6fa9a417..981f21119 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -349,7 +349,7 @@ Each member of this list is a list with three members:
{
tfile<-tempfile()
write.table(object, file=tfile, sep=\"\\t\",
-na=\"nil\",row.names=%s,col.names=%s,
+na=\"\",row.names=%s,col.names=%s,
quote=FALSE)
file.rename(tfile,transfer.file)
},
--
2.20.1
Best regards,
Jeremie
On Saturday, 16 Jan 2021 at 00:19, Berry, Charles" via "General discussions
about Org-mode. wrote:
>> On Jan 14, 2021, at 3:42 PM, Brett Presnell wrote:
>>
>>
>> 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.
>
>> Regardless, I generally (always?) want na=\"\" for this, so I am finding
>> all those "nil"s very annoying, and the only way that I see to defeat
>> them is to redefine org-babel-R-write-object-command.
>>
>> If there is no reason for the current behavior (doubtful I know) and if
>> I am not missing an obvious work-around, then I would like to suggest
>> changing this behavior. Otherwise, would it be feasible to add an
>> option for R code blocks (:nastring?) where one could specify the NA
>> replacement string?
>>
>> What do you think? It's easy to suggest I know and certainly beyond my
>> elisp coding skills at present, but I am supposing that someone more
>> fluent in elisp could do this safely without too much trouble.
>>
>
> 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'.
>
> Adding another header arg qualifies as feature creep and in this case would
> require non-trivial work to implement.
>
> HTH,
>
> Chuck
>
--
Jeremie Juste
Re: na=\"nil\" in ob-R.elo
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 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,
Re: na=\"nil\" in ob-R.elo
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, -- Jeremie Juste
Re: na=\"nil\" in ob-R.elo
> On Jan 14, 2021, at 3:42 PM, Brett Presnell wrote: > > > 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. > Regardless, I generally (always?) want na=\"\" for this, so I am finding > all those "nil"s very annoying, and the only way that I see to defeat > them is to redefine org-babel-R-write-object-command. > > If there is no reason for the current behavior (doubtful I know) and if > I am not missing an obvious work-around, then I would like to suggest > changing this behavior. Otherwise, would it be feasible to add an > option for R code blocks (:nastring?) where one could specify the NA > replacement string? > > What do you think? It's easy to suggest I know and certainly beyond my > elisp coding skills at present, but I am supposing that someone more > fluent in elisp could do this safely without too much trouble. > 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'. Adding another header arg qualifies as feature creep and in this case would require non-trivial work to implement. HTH, Chuck
