From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AL3KIiHXAGDoegAA0tVLHw (envelope-from ) for ; Thu, 14 Jan 2021 23:43:29 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id 0Dp8HiHXAGDxIwAAbx9fmQ (envelope-from ) for ; Thu, 14 Jan 2021 23:43:29 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id EA8649403A2 for ; Thu, 14 Jan 2021 23:43:28 +0000 (UTC) Received: from localhost ([::1]:34260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0CH1-0008DE-Ka for larch@yhetil.org; Thu, 14 Jan 2021 18:43:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42068) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0CGJ-0008D7-KY for emacs-orgmode@gnu.org; Thu, 14 Jan 2021 18:42:43 -0500 Received: from mx0a-000b4001.pphosted.com ([148.163.146.25]:63346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0CGI-0007R9-1d for emacs-orgmode@gnu.org; Thu, 14 Jan 2021 18:42:43 -0500 Received: from pps.filterd (m0166815.ppops.net [127.0.0.1]) by mx0a-000b4001.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10ENdwvu015512 for ; Thu, 14 Jan 2021 23:42:40 GMT Received: from az1-msa-prod02.server.ufl.edu (az1-msa-prod02.server.ufl.edu [128.227.74.23]) by mx0a-000b4001.pphosted.com with ESMTP id 362y6t05rk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 14 Jan 2021 23:42:40 +0000 Received: from ls-presnell (ip24-170-195-154.ga.at.cox.net [24.170.195.154]) (Authenticated sender: presnell) by az1-msa-prod02.server.ufl.edu (Postfix) with ESMTPSA id 2947B4004D for ; Thu, 14 Jan 2021 18:42:39 -0500 (EST) User-agent: mu4e 1.4.13; emacs 28.0.50 From: Brett Presnell To: emacs-orgmode@gnu.org Subject: na=\"nil\" in ob-R.elo Date: Thu, 14 Jan 2021 18:42:38 -0500 Message-ID: <87h7njdr0x.fsf@ufl.edu> MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-14_10:2021-01-14, 2021-01-14 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1034 priorityscore=1501 malwarescore=0 mlxlogscore=805 mlxscore=0 lowpriorityscore=0 spamscore=0 impostorscore=0 bulkscore=0 phishscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101140137 Received-SPF: pass client-ip=148.163.146.25; envelope-from=presnell@member.fsf.org; helo=mx0a-000b4001.pphosted.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.26 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=member.fsf.org (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: EA8649403A2 X-Spam-Score: -2.26 X-Migadu-Scanner: scn1.migadu.com X-TUID: yMS25Ql1uv3C 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.