na=\"nil\" in ob-R.elo

na=\"nil\" in ob-R.elo

[Brett Presnell]

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?

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.

Re: na=\"nil\" in ob-R.elo

[Berry, Charles via General discussions about Org-mode.]

> On Jan 14, 2021, at 3:42 PM, Brett Presnell <presnell@member.fsf.org> 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

Re: na=\"nil\" in ob-R.elo

[Jeremie Juste]

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

[Brett Presnell]

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 <jeremiejuste@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,

Re: na=\"nil\" in ob-R.elo

[Jeremie Juste]

[-- Attachment #1: Type: text/plain, Size: 104 bytes --]


Hello,

Thanks again for reporting this. With the attached patch I'll remove
nil replacement for NA. 


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-For-results-value-return-empty-string-instead-of-nil.patch --]
[-- Type: text/x-diff, Size: 946 bytes --]

From 90881079d431a8af3cba5be14ecf882735ed7a6a Mon Sep 17 00:00:00 2001
From: Jeremie Juste <jeremiejuste@gmail.com>
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


[-- Attachment #3: Type: text/plain, Size: 1685 bytes --]


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 <presnell@member.fsf.org> 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