From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id 2CHAJ2HNWGbCAgAAe85BDQ:P1 (envelope-from ) for ; Thu, 30 May 2024 21:02:57 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id 2CHAJ2HNWGbCAgAAe85BDQ (envelope-from ) for ; Thu, 30 May 2024 21:02:57 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JUehXwby; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1717095777; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=hsc0MQg0ct/klsfDxG5yBYlNtO2/YtczzyvulAhTvcQ=; b=cV+eDuK0C2BppJAlEYpAxO3nUCftopqUwoIhhQNVfFbmXmCbXeXu/YblEMvKG4F6X7YJf7 Uvofie+PjRpWehs8qGwWRDLCF+PE2O4GTD40bDJhYd7xAseZx47/VTLbVYwPJDI8y/fX3a SYSl1nbhxxAkmBxQMuiYRTFvf0UZI2L0VGmHEZ0WChjdt7hQiPT4XWsTcrBuysHou+PdXP W2X0i9MR6I/zOqhBICcJ5jNp3Nqn180gdpTjsfgDR/4qy54lC2sm1So93D6zIOFPL+/WSv tEGlym3Vaim94iNt2Sso7p1lfQ/zHPBRKjikV8FdA4AJ0tVSq1XlL2KIJyUuBg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JUehXwby; 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"; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1717095777; a=rsa-sha256; cv=none; b=kxaiowO0NVO1vDz+PXMOVolWGaZ/zZAurwn5nS1cmzt/u/+x4klTMQcETFqsADjeOSnS9e ZpTtOTwNgjvLbwhqSoyFJ5ZUIUGo30ZaP3tnEUdo+sgFnCvsYHHD1hdHYZ30GYwUDMkmTU ECEMJ5Ru6m4NKGBHtHFep35K4SGz66k//8HAy/EXbZ08FGZgvKCYL8LRHVwM9Z1TyAdtqK +tXwc4l7ov21905KafRDjjyOgYYKqjKIAMJzLHB9uv3gsy3bX1/o6xNAvVrLqjGnooi0up uRBa4tJixJAHnsotBh0fk3RNb8vY8sZnH9ayTpNxtKZsE2nnaY3iQ3z1nRHYrg== 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 5378168503 for ; Thu, 30 May 2024 21:02:57 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCl2F-0008VY-9v; Thu, 30 May 2024 15:01:59 -0400 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 ) id 1sCl2D-0008V2-EX for emacs-orgmode@gnu.org; Thu, 30 May 2024 15:01:57 -0400 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sCl2B-0006yt-DH for emacs-orgmode@gnu.org; Thu, 30 May 2024 15:01:57 -0400 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-42120fc8d1dso13320185e9.2 for ; Thu, 30 May 2024 12:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717095712; x=1717700512; darn=gnu.org; h=mime-version:date:references:in-reply-to:subject:cc:to:from :message-id:from:to:cc:subject:date:message-id:reply-to; bh=hsc0MQg0ct/klsfDxG5yBYlNtO2/YtczzyvulAhTvcQ=; b=JUehXwbyztCy2p1w61vcqBEafV7sTzIsIGo1clLGtso3RPD2RQ3N1avakeAREp5yzk HjDpkJUY3SNFjVNiruUHyghIZk0YsFcAlbQQjoGrYYMoOFzN6PixIw6D9Hdcq9u5L/fL 0Q+0z/knWQb0DfmXH07u/2DSmit/xQetNCNYUztQdoodxUr4P1avhnrAEGGYCdfG6d/P TBMi3BktTD1nCbKLKFofprXfchbnuiufeUxET7pXVTM80lRrGjrOUZJB4Wu6aPz3AZib x6UAglUxogDVjY6BsZc5wwS2ynBBpjJB2Xn5ruv/YKrNvEpNW6Y8JhdGzAt52alGK8qz dmZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717095712; x=1717700512; h=mime-version:date:references:in-reply-to:subject:cc:to:from :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hsc0MQg0ct/klsfDxG5yBYlNtO2/YtczzyvulAhTvcQ=; b=MkHn/w9S1bC1mvR1aUzGQ/dbTlvYv35kCB/Mt4uWzz21k0xI9BKpavgET+mDwpCgNq CUeORwk5+bpVS5/w5YM5vwzixP59Fsi2iZnaN+26UtacR/OM9QoolH3LXYzAiDMlsvxB 6S70FOzkwHyKvAw5eO6Kr09m3Fn0kXlEsWxBqfCRdkdqOCRbVGXhJD+wvHIKh2BCOLeY hSy0KPPLr1gPiPHz+m7D5kBVTx4iDPuMub4miFv9zZlQufGX4EbcQ9iy8MXYmSrf4qLS SssP/jt7Mv0loFWOC1g8ItvLvj5HRMmGrxJH0WZKI5fR9vhPfU+gWnO6c823xwiaTi12 SnAQ== X-Gm-Message-State: AOJu0YwFrymT1JAKjD0gvQ/X0oRvv4Q9Ubx/61jKMBte4ppHvqR97E9O EN5zffksKwYiYzwJx8K+d4MTck/PwbTE+fE/HfPwVeFiWCJl0IZ/USYfGQ== X-Google-Smtp-Source: AGHT+IFlZdHpkZKsF2nUfJunNxM/DPp2sMNJ9v90sd+Xlqs7V0V0c4hRa7Hbz8tLZKJ7hITsIKSMoA== X-Received: by 2002:a05:600c:5129:b0:421:2b3e:3a22 with SMTP id 5b1f17b1804b1-4212b3e3d52mr3777305e9.14.1717095711762; Thu, 30 May 2024 12:01:51 -0700 (PDT) Received: from keynux ([2a01:e0a:505:3460:1c18:688d:ece4:372e]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42127056e25sm32671165e9.6.2024.05.30.12.01.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 May 2024 12:01:51 -0700 (PDT) Message-ID: <6658cd1f.050a0220.f6605.de1a@mx.google.com> Received: by keynux (sSMTP sendmail emulation); Thu, 30 May 2024 21:01:49 +0200 From: Bruno Barbier To: Ihor Radchenko Cc: emacs-orgmode , Jack Kamm , Matt Subject: Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)) In-Reply-To: <87o78vwnds.fsf@localhost> References: <87o7d0mm54.fsf@localhost> <65df0895.df0a0220.a68c8.0966@mx.google.com> <87edct0x2w.fsf@localhost> <65e30609.050a0220.89c06.1798@mx.google.com> <87a5ng7uoq.fsf@localhost> <65e9f49b.df0a0220.11103.1c10@mx.google.com> <87ttlhki9e.fsf@localhost> <65eb1e60.050a0220.337b2.a0f4@mx.google.com> <87frwuxy1b.fsf@localhost> <65f95bf2.050a0220.6d051.c8b1@mx.google.com> <87plvpjj76.fsf@localhost> <65fc06c1.5d0a0220.0d53.efdc@mx.google.com> <87frwjlr1a.fsf@localhost> <6601b872.050a0220.31a67.5a55@mx.google.com> <87le63c3qy.fsf@localhost> <660ed63d.050a0220.36fdd.af23@mx.google.com> <87cyqwyvgw.fsf@localhost> <66225435.5d0a0220.f60e4.c590@mx.google.com> <87r0f02vq2.fsf@localhost> <664f6f54.050a0220.10342.b002@mx.google.com> <87o78vwnds.fsf@localhost> Date: Thu, 30 May 2024 21:01:49 +0200 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::32e; envelope-from=brubar.cs@gmail.com; helo=mail-wm1-x32e.google.com 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 X-Spam-Score: -9.68 X-Migadu-Queue-Id: 5378168503 X-Migadu-Scanner: mx10.migadu.com X-Migadu-Spam-Score: -9.68 X-TUID: UwSLWBSHabNN Ihor Radchenko writes: > Bruno Barbier writes: > > I am attaching some minor edits I'd like to propose on top of your > latest branch. I've applied your patch. Thanks. > Also, some more questions. > >> ;; (setq my-rlock >> ;; (org-pending (cons (point) (mark)) >> ;; (lambda (outcome) >> ;; (pcase outcome >> ;; (`(:success ,result) (goto-char END) (insert result)) >> ;; (`(:failure ,err) (message "Failed: %s" err)))))) > > 1. It is more natural in Elisp to pass regions as two parameters: BEG > and END, not a cons cell. I rewrote the example so that it's complete and can be uncommented and evaluated. With the new example, it's less obvious which is more natural. > 2. Note that (point) may be _after_ (mark). AFAIU, you code assumes > that point is always before the mark. You may want to address this. Right. I'm not using those in the new example: problem solved ;) > 3. ON-OUTCOME is optional. What happens if none is provided? No function is called. And thus, no value is returned, so no mark. It's like calling a function that does nothing and return nil. > 4. In the `org-pending' docstring you say "ON-OUTCOME is non-nil, call > it with the reglock and the outcome", but the example shows a lambda > accepting a single argument. Something is off. I'm afraid that this > example will not work if copy-pasted. > You're right. Sorry. I'm now using using a fully working example. >> ;; (org-pending-send-update my-rlock (list :progress "Not ready yet.")) >> ;; (org-pending-send-update my-rlock (list :progress "Coming soon.")) > > Should the progress message always be a string? No. It may currently be any data. org-pending will format it as a string that fits on one line. >> ;; (org-pending-send-update my-rlock (list :success 1)) > > What will org-pending do with :success 1? Will it replace region with > "1" or will it do something else? That's the job on ON-OUTCOME to convert/format/append/prepend/replace some content if needed, on :success and/or on :failure. >> ;; (org-pending-send-update my-rlock (list :failure "Some error!")) > > I am slightly confused by this calling convention. Why not simply > > (org-pending-send-update my-rlock :failure "Some error!") Because one message update is one value, either: (list :success value) or (list :failure err) or (list :progress data) On :success/:failure, this message is also a valid outcome, and it's the same value that ON-OUTCOME will receive, as one single entity. When listing artificial calls like this, it does look suboptimal; but, in general, it's simpler to have a real value we can store, pass around and return. > >> ;; (setf (org-pending-reglock-insert-details-function my-reglock) >> ;; (lambda (rl _start _end) >> ;; (insert (format "%s" (org-pending-reglock-property rl :my-prop))))) > > Are there any standard properties? It would be nice to list them in a > table as well. There are no standard properties. All required properties have been hard-coded in the cl-defstruct. > Also, you can show an example of _setting_ :my-prop property. I removed the use of `org-pending-reglock-property' from the example; I think it was a mistake to introduce that advanced feature here. The documentation of the function `org-pending-reglock-property' explains how to set a property. >> ;; If the user kills a buffer, or, kills Emacs, some locks may have to >> ;; be killed too. The library will ask the user to confirm if an >> ;; operation requires to kill some locks. See the field >> ;; `before-kill-function' of REGLOCK object, if you need to do >> ;; something before a lock is really killed. For example, if you like >> ;; to kill a MY-BUFFER before MY-LOCK is killed, you can do: >> ;; >> ;; (setf (org-pending-reglock-before-kill-function my-reglock) >> ;; (lambda (_rl) (kill-buffer my-buffer))) > > It would be nice to have an example that will also send a signal to > process, as it is probably the most commonly used way to utilize > org-pending. For my many use cases, that would always be a mistake to kill the process: an OS process is always in charge of many locks. More importantly, to find a self-contained working readable example might be a challenge. We could add a function 'org-pending-shell-command-on-region' in org-pending, that could be used as an implementation example, like `org-pending-user-edit', `org-babel-execute-src-block', etc. > From `org-pending' docstring: > >> If ON-OUTCOME returns >> a region (a pair (start position . end position)), use it to report the >> success/failure using visual hints on that region. If ON-OUTCOME >> returns nothing, don't display outcome marks. > > What if ON-OUTCOME returns something that is not a cons cell and not nil? > Then org-pending would have raised some error at some point, as it's not a valid value; the doc says that ON-OUTCOME may return a region or nothing. I added a test so that org-pending will now scream immediately if ON-OUTCOME returns an invalid value. I've updated my public branch, Let me know what you think, Thanks, Bruno