From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp10.migadu.com ([2001:41d0:8:6d80::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms5.migadu.com with LMTPS
	id OMYxJW5l5mOAzQAAbAwnHQ
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Fri, 10 Feb 2023 16:40:30 +0100
Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp10.migadu.com with LMTPS
	id gH8sJG5l5mMLGAEAG6o9tA
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Fri, 10 Feb 2023 16:40:30 +0100
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 42E082B00A
	for <larch@yhetil.org>; Fri, 10 Feb 2023 16:40:30 +0100 (CET)
Received: from localhost ([::1] helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.90_1)
	(envelope-from <emacs-orgmode-bounces@gnu.org>)
	id 1pQVV1-0001Ry-5p; Fri, 10 Feb 2023 10:39:43 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ruijie@netyu.xyz>) id 1pQVUz-0001Rc-PJ
 for emacs-orgmode@gnu.org; Fri, 10 Feb 2023 10:39:41 -0500
Received: from netyu.xyz ([152.44.41.246] helo=mail.netyu.xyz)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <ruijie@netyu.xyz>) id 1pQVUx-0005Xj-Gu
 for emacs-orgmode@gnu.org; Fri, 10 Feb 2023 10:39:41 -0500
Received: from smtpclient.apple (<unknown> [222.248.4.98])
 by netyu.xyz (OpenSMTPD) with ESMTPSA id aedbf01c
 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); 
 Fri, 10 Feb 2023 15:39:35 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Subject: Re: Problem with let/cl-letf binding stuff with org-capture
In-Reply-To: <AM9PR09MB4977E7E66F2E6BD0345DF46496DE9@AM9PR09MB4977.eurprd09.prod.outlook.com>
Cc: emacs-orgmode@gnu.org
Date: Fri, 10 Feb 2023 23:38:51 +0800
Message-Id: <E2EB9155-238D-4423-80A0-B64D934FEBF8@netyu.xyz>
References: <AM9PR09MB4977E7E66F2E6BD0345DF46496DE9@AM9PR09MB4977.eurprd09.prod.outlook.com>
To: Arthur Miller <arthur.miller@live.com>
X-Mailer: iPhone Mail (20D47)
Received-SPF: pass client-ip=152.44.41.246; envelope-from=ruijie@netyu.xyz;
 helo=mail.netyu.xyz
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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.29
Precedence: list
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/emacs-orgmode>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
 <mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Reply-to:  Ruijie Yu <ruijie@netyu.xyz>
From:  Ruijie Yu via "General discussions about Org-mode." <emacs-orgmode@gnu.org>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
X-Migadu-Country: US
X-Migadu-Flow: FLOW_IN
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org;
	s=key1; t=1676043630;
	h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date:
	 message-id:message-id:to:to:cc:cc:mime-version:mime-version:
	 content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:
	 in-reply-to:in-reply-to:references:references:list-id:list-help:
	 list-unsubscribe:list-subscribe:list-post;
	bh=7+viklzjmT3f/9uG4NSUkxlua2+VcliYoCHCpw9frBI=;
	b=ncZTvDdUHyJtWpQD96lcviulOV7LeCtJfEE5JJYdX7RXl60rWzKC75lkxSunQglSxkQ5sX
	uQgV8i8ez0To9G4OX6BXwVJ1rlOLVIAUtISPvuFvBirvkq5Jg5jv+QJez+lSPFdMt44MAK
	Bhdfcb9teRd8x0TO+VTbEifuQS5HPZM3tWNG2wKJsjWj7ZdJpKBUY82wXRqI5M8RoDj+ph
	9z2GEkc+gUZtxRkXBWSgEQxVdlhzbs8JKCy/9fz4Ic8bQ+L1XQcLCWhU1pw6f2tdyV70Wd
	DUTiyLOXrHkJyIPz64bwEn6Z4tZ12z3+p6p1Fzbx/I75YHpKKHdG9CGJF6rWJQ==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=none;
	dmarc=pass (policy=none) header.from=gnu.org;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"
ARC-Seal: i=1; s=key1; d=yhetil.org; t=1676043630; a=rsa-sha256; cv=none;
	b=D9ipMEeWA00NILcYI89KyEz0nmXQa4sek2H2VxLq38+5ZaeaaRw0GK9dFUzaL5UKoxPsrp
	Yo2zCpj8ehoga8NjKWb13rqzXZ/pJFmeJCtJ8Z+7ylvKT6Xw5NMYReYSRsfBEvPqZVCucN
	zIclK55e4NOri7o66VfqLnJ5E3NgE+/pVHd6i1aj/W73NB7bLVwmWgwkDe15JXMqKmZtwu
	o05sXOnYj991zpJ2FcOAlKE1X7A0c0bzdiSj4GRqPbNDrKwdmXjIpIjf86xfAI8KxqEmtl
	XSZn8FvR73zy3R+beqbABMhUROkFr/7uKzluWFK87yz552utpUR24/DR15eLJA==
Authentication-Results: aspmx1.migadu.com;
	dkim=none;
	dmarc=pass (policy=none) header.from=gnu.org;
	spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"
X-Migadu-Spam-Score: -2.91
X-Spam-Score: -2.91
X-Migadu-Queue-Id: 42E082B00A
X-Migadu-Scanner: scn1.migadu.com
X-TUID: RCKz44qhBZ30

Hi Arthur,

Please excuse my brevity and semi-random line of thought, as I=E2=80=99m rep=
lying on mobile right now.  See below.=20

> On Feb 10, 2023, at 23:11, Arthur Miller <arthur.miller@live.com> wrote:
>=20
> =EF=BB=BF
> Based on a Reddit thread:
>=20
> https://www.reddit.com/r/emacs/comments/10xhvd8/a_little_readstring_utilit=
y_using_an_org_mode/j7xziao/?context=3D3
>=20
> I did a small experiment to see if I can re-use org-capture, to just captu=
re a
> string from a buffer, without actually writing to any file.
>=20
> My plan was to just let-bind org-capture-finalize with cl-letf:
>=20
> #+begin_src emacs-lisp
> (defun my-read-string ()
> (cl-letf (((symbol-function 'org-capture-finalize) ;; C-c C-c
>           (lambda (&optional _) (interactive "P") (buffer-string)))
>          ((symbol-function 'org-kill-note-or-show-branches) #'kill-buffer)=
) ;; C-c C-k
>  (let ((org-capture-templates '(("s" "string" plain (function ignore)))))
>    (org-capture nil "s"))))
> #+end_src

Based on my somewhat-limited experience with CL (and elisp), I have never se=
en this particular type of letf structure.  What I am used to seeing and wri=
ting is the following:

(cl-letf ((f (x) (1+ x))
   (1+ (f 2)))
; =3D> 4

In particular, IIUC, I don=E2=80=99t think you would need symbol-function he=
re.  Maybe you can learn more from the docstring of cl-letf than me trying t=
o drain my memory on this topic without reference.=20

Also, in the code snippet you provided, what *should* org-capture-finalize b=
e?  A function that can be called like this:

   (org-capture-finalize arg1 arg2)

? Or a variable containing a function (reference) that can be called like th=
is:

   (funcall org-capture-finalize arg1 arg2)

?  In the former case you might be able to use cl-letf, and in the latter ca=
se you should use let with a lambda value.=20

> Unfortunately, that does not work. Regardless of binding, and if I used cl=
-letf
> or cl-flet or cl-labels, or old let, or something brewed on the internet, t=
he
> binding org-capture see for org-capture-finalize, is the original one from=

> org-capture.el.
>=20
> My second experiment was to abstract the finalize function into a funcalla=
ble
> fariable in org-capture.el (I have patched org-capture.el with this):
>=20
> #+begin_src emacs-lisp
> (defvar org-capture-finalizer #'org-capture--default-finalize)
>=20
> (defun org-capture-finalize (&optional stay-with-capture)
> "Finalize the capture process.
> With prefix argument STAY-WITH-CAPTURE, jump to the location of the
> captured item after finalizing."
> (interactive "P")
> (funcall org-capture-finalizer stay-with-capture))
>=20
>=20
> (defun org-capture--default-finalize (&optional stay-with-capture)
> "Default implementation for org-capture finalizer function."
>=20
> ;; this is the original org-capture-finalize just renamed to "default-fina=
lize"
> )
> #+end_src
>=20
> So I could then have something like this (never mind C-c C-k function bein=
g
> removed):
>=20
> #+begin_src emacs-lisp
> (defun my-read-string ()
> (let ((org-capture-templates '(("s" "string" plain (function ignore))))
>      (org-capture-finalizer
>       (lambda (&optional _) (interactive "P") (buffer-string))))
>  (org-capture nil "s")))
> #+end_src
>=20
> However I see that the binding for the org-capture-finalizer, in capture b=
uffer,
> is still the default 'org-capture--default-finalize' and not my lambda.

I guess this answers part of my question in my previous paragraph.  Is org-c=
apture-finalizer defined via defvar?  If so, does it help if you put an empt=
y defvar before the let binding?  If not, maybe someone actually using Emacs=
 right now can be of more help here.=20

> I am really not an expert on emacs lisp; and I do understand that this is
> somewhat "creative" use of org-capture (to put it nicely :-)), but I would=
 like
> to understand what is going on here.
>=20
> I don't understand why let-binding here does not work? If I take (symbol-f=
uncton
> 'org-capture) I see it is a closure. I am not sure if it has something wit=
h the
> problem to do? I have tested to disable lexical binding, re-eval things, b=
ut
> the let-binding seems rock stable :). Nothing makes org-capture to reconsi=
der
> using my local let-binding.
>=20
> I would really like to understand this, so please if someone can explain i=
t, I
> will appreciate to hear.
>=20
> Thanks in advance
> /arthur

Best,


RY=