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 KOe6IRE6bF9yCwAA0tVLHw (envelope-from ) for ; Thu, 24 Sep 2020 06:17:53 +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 kAmFHRE6bF9ZTgAAbx9fmQ (envelope-from ) for ; Thu, 24 Sep 2020 06:17:53 +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 A4BA9940239 for ; Thu, 24 Sep 2020 06:17:52 +0000 (UTC) Received: from localhost ([::1]:54638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLKZi-0004fF-DS for larch@yhetil.org; Thu, 24 Sep 2020 02:17:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLKZ0-0004eu-O3 for emacs-orgmode@gnu.org; Thu, 24 Sep 2020 02:17:06 -0400 Received: from mail-pj1-x1042.google.com ([2607:f8b0:4864:20::1042]:37978) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLKYx-0000X0-DA for emacs-orgmode@gnu.org; Thu, 24 Sep 2020 02:17:06 -0400 Received: by mail-pj1-x1042.google.com with SMTP id u3so1046721pjr.3 for ; Wed, 23 Sep 2020 23:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=D96wqE32f/xdxl1Tv1q9aDiyyrSO+mSdKtrRoYWWEfE=; b=P72C79mYNTjyEt0pK5xx6bosDCyPiufvAmJTdN0LJI08O2hmN+hJ1n6Jt16rrA60hz zSJsDXJdXZ4+il1EnVIURUB50jQtx+244YD6fHdUOWYLYUYNcnis5S/Wzkaq7gKp9GHl DucxGeFezKZzfSSgnhV1YhBPk17JIMvshXVg+5vB0u70J1u/GiKVXeWuBZvDL/nk5DNM NR9QKCbLt6DsZQc5S5X3SOGdfATdE/246SUMvfgi+o01u8KKUw931TgaZzGMX+Ef8obT vH3C14UXlk/sN1xXgOuvdf5mZSihk/F7LRGcZo1vBWvNkuE8BlunauVOFhoNj1o7E50O v0hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:cc:subject:in-reply-to:references :date:message-id:mime-version:content-transfer-encoding; bh=D96wqE32f/xdxl1Tv1q9aDiyyrSO+mSdKtrRoYWWEfE=; b=pgArF0KMqk33NdAV8S16OduvqfrQvg8rsL8eQkYgSpAoeXP5PbyrQxy1NayAi2WJuX jA88pjk+EKX29wZfJKRtSWKlfqzEnW7lV+QCUr1w3ghxWRv78/DV3vluueCNbcFYXwCp FgqleqOXJhuMojFhOEvoFOCFnQBpHrf/2F+B0Ufcn4GkALfZgFlhLqO/GYkI2Tt2S0FT gdKL033oNmr3BIonscaz6gTZP+3Zn3g7Wpa4iXMEWY5wgELXnoIAKuQpMreO3He48xUw Y1gm9piuyC/KDw2EKJDgvqvWdm7e7XjCh+EzG1V+QXmpQ+Z9yP1y7fNkAT2e0mloyOfN F/AQ== X-Gm-Message-State: AOAM5314MoIg5Wod1F0Qr8ujBbKV7iEMuRcENxdUXef1Wikf5RFVfBd2 3L09jpiOIR0xFgZvAm02W3Qc0JOd5ekvOA== X-Google-Smtp-Source: ABdhPJwJOg77ecX2/66im50KMffITwnz+K6AWCgqWeNzrtBrnauZtqivNvLJvSnyVD3nhwm54n/GLA== X-Received: by 2002:a17:902:b185:b029:d1:e5e7:bdd1 with SMTP id s5-20020a170902b185b02900d1e5e7bdd1mr3236254plr.49.1600928218743; Wed, 23 Sep 2020 23:16:58 -0700 (PDT) Received: from ryzen3950 (c-73-71-89-135.hsd1.ca.comcast.net. [73.71.89.135]) by smtp.gmail.com with ESMTPSA id d8sm1184800pjs.47.2020.09.23.23.16.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 23 Sep 2020 23:16:57 -0700 (PDT) From: Matt Huszagh To: Kyle Meyer Subject: Re: [PATCH] Omit file description when :file-desc has nil value In-Reply-To: <87a6xfvjck.fsf@kyleam.com> References: <87r1rf35bb.fsf@kyleam.com> <87pn6uzq41.fsf@gmail.com> <877dsv3r1w.fsf@gmail.com> <87a6xfvjck.fsf@kyleam.com> Date: Wed, 23 Sep 2020 23:16:53 -0700 Message-ID: <87eemrzokq.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::1042; envelope-from=huszaghmatt@gmail.com; helo=mail-pj1-x1042.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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: , Cc: , Emacs-Orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=P72C79mY; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (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-Spam-Score: 0.09 X-TUID: TxE6mA2kkVGC Kyle Meyer writes: > But it's not a direct comparison against that use case and the use case > you want to support. The potential breakage of existing documents is a > big factor to go against. Yep, I agree. I think my phrasing could have just been better. I meant to include the breakage as a factor against. > Unfortunately, such a kludge is how I'd suggest to move forward. > Perhaps an empty string, or perhaps any value (e.g., ":file-desc []") > that org-babel-read won't treat as a string or nil (the two cases that > mean something right now). The rough patch below is an example of the > latter. I like this solution better than mine. I guess it's still a bit of a hack, but it doesn't seem to be one that could break a use case, whereas the empty string could conceivably be intended, though I'm still not sure why. > I'm not sure I get this. What's next down the road in this scenario? > With something like the above kludge, haven't we exhausted the cases for > :file-desc? Yes I think you're right. I was referring to my solution of an empty string, which I didn't see a personal use for, but felt it might be a valid use case for someone else. I really can't think of any reason the empty vector would otherwise be valid. > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > index 7300f239e..4483585a1 100644 > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -646,6 +646,13 @@ (defun org-babel--expand-body (info) > (replace-regexp-in-string > (org-src-coderef-regexp coderef) "" expand nil nil 1)))) >=20=20 > +(defun org-babel--file-desc (params result) > + (pcase (assq :file-desc params) > + (`nil nil) > + (`(:file-desc) result) > + (`(:file-desc . ,(and (pred stringp) val)) val) > + (_ nil))) > + > ;;;###autoload > (defun org-babel-execute-src-block (&optional arg info params) > "Execute the current source code block. > @@ -749,8 +756,7 @@ (defun org-babel-execute-src-block (&optional arg inf= o params) > (let ((*this* (if (not file) result > (org-babel-result-to-file > file > - (let ((desc (assq :file-desc params))) > - (and desc (or (cdr desc) result))))))) > + (org-babel--file-desc params result))))) > (setq result (org-babel-ref-resolve post)) > (when file > (setq result-params (remove "file" result-params)))))) > @@ -2257,9 +2263,8 @@ (defun org-babel-insert-result (result &optional re= sult-params info hash lang) > (setq result (org-no-properties result)) > (when (member "file" result-params) > (setq result (org-babel-result-to-file > - result (when (assq :file-desc (nth 2 info)) > - (or (cdr (assq :file-desc (nth 2 info))) > - result)))))) > + result > + (org-babel--file-desc (nth 2 info) result))))) > ((listp result)) > (t (setq result (format "%S" result)))) > (if (and result-params (member "silent" result-params)) > diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el > index 648e9c115..e7a292de3 100644 > --- a/testing/lisp/test-ob.el > +++ b/testing/lisp/test-ob.el > @@ -1084,7 +1084,16 @@ (ert-deftest test-ob/file-desc-header-argument () > (org-babel-execute-src-block) > (goto-char (point-min)) > (should (search-forward "[[file:foo][bar]]" nil t)) > - (should (search-forward "[[file:foo][foo]]" nil t)))) > + (should (search-forward "[[file:foo][foo]]" nil t))) > + (should (string-match-p > + (regexp-quote "[[file:foo]]") > + (org-test-with-temp-text " > +#+begin_src emacs-lisp :results file :file-desc [] > + \"foo\" > +#+end_src" > + (org-babel-next-src-block) > + (org-babel-execute-src-block) > + (buffer-substring-no-properties (point-min) (point-max)))))) >=20=20 > (ert-deftest test-ob/result-file-link-type-header-argument () > "Ensure that the result is a link to a file. This patch looks good. I've tested it and it works well for me. Thanks for coming up with a good solution! I think the one thing still missing is some documentation in the info manual. Something along the lines of The =E2=80=98file-desc=E2=80=99 header argument defines the descriptio= n (see *note Link Format::) for the link. If =E2=80=98file-desc=E2=80=99 has no va= lue, Org uses the generated file name for both the =E2=80=9Clink=E2=80=9D and =E2=80= =9Cdescription=E2=80=9D parts of the link. If you want to omit the description (i.e., [[link]]), you can either omit the =E2=80=98file-desc=E2=80=99 header argument or= provide it with an empty vector (i.e., :file-desc []). Feel free to add this (or something else) to your patch. Or, if you'd prefer that I created a patch for it, let me know. Matt