From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id UEbIMtAPBGZ3dgAA62LTzQ:P1 (envelope-from ) for ; Wed, 27 Mar 2024 13:23:44 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id UEbIMtAPBGZ3dgAA62LTzQ (envelope-from ) for ; Wed, 27 Mar 2024 13:23:44 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=E9O05Euq; 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=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1711542224; 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=6tfMhR2HzTe9WAu+ts0D5x0Psj+anvpExZbR3VB9dPE=; b=mDKApl/KjOiy6TduTJFkyDdNlRhNZ476bfjqM8FhZ8fOqYzBW7JOrH7AqhOU2TRjWfYL/b lXkoM1QFXFNPqxQKeNkjG5lEuMTVNKqOe2vF2THc9BaKMN6rMICh0+EbPfzFSXmt+wUwOf R6Mr7op1mGjj8HYyM+Ex5Xnd/v3uCOgBS7iAIUmotTjyItE+/aDuRPx1VOWfqtklMzbd2k MQc4m1sxY/zf6moGvcq+IhI78dtAKzEWcU7YpqrAIapHUbni4unktqdI5mXeSrRgIT3UI5 Esj7jdNqg4Zrs2Fv7YIQAAL1F2eibXPOl9KI0hwpFAToVN9sym0AXfHX8OYmmA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=E9O05Euq; 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=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1711542224; a=rsa-sha256; cv=none; b=q4K9Oyp4FVkJCWCGLPsZ7Y7QUrP4kOWY02dgWwruzhBl9L+2t9sNYngZFtsPbbAXQfjDvV xUUejT8OPAZHsKo+W0gtcp31/FeoXPjrBaxQgAJgux4DtNOsKIGnbPMDjbzauKPEVdvLV8 glh+Gd6YSefIGj3SfrQMbFqm6NcnmgggNiuhkuD3ZQR2uS69rYkPo5HwLy+oSbSzcABoKT IIYwCMGBpuC5yQQXe1oBxB+M9iQaVh4ekXhC/wL4Rf3UeNYWSLSexmLfox/WB4XDzb6W9P d32orZ3TTRqmX6mf94nGjdyvJMvzCmYGn/alPiiWsMe5O++ZNHCnPENjjwZMlQ== 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 8CEE9A96C for ; Wed, 27 Mar 2024 13:23:44 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rpRSw-00043Z-W5; Wed, 27 Mar 2024 07:29:11 -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 1rpRSv-0003yX-2h for emacs-orgmode@gnu.org; Wed, 27 Mar 2024 07:29:09 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rpRSs-00087M-9r for emacs-orgmode@gnu.org; Wed, 27 Mar 2024 07:29:08 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id BE28724002B for ; Wed, 27 Mar 2024 12:29:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1711538943; bh=HuBPWepV1qyaGUyTO5Db5VGHSvt7AgJtx+T4ftofIYE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=E9O05EuquQ05ljW0i707kNECfHwckGtCp323T2zXKjI0QBHhruVO5ncAJxhYwuvo/ 9PORpDifm0DtuXTTXmr4pwJo9RkE9Q3hkpvTfItmN3fyJU1F5sMoodlXP0zitIaEtd rrWSms70tJ3JoUOkaX6Caov8TnS5y8Ewevq/+ZY7ONcAFEacoMBfOCveE6qxXECyKW 4wRSaNVZUAiQ7zVBSpLnchUleIUMOylLjxtbCzU7DVIvMif1LtyxkWZGSs81rUnKW2 tQUwZ+K29u4f88N5mK7dZQ8UEwvFOYzTVSmLx17oub+ixBzfaodwhy54/o7pxmNO/C dWX7jS5MUlAAg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4V4PZQ4lpjz9rxX; Wed, 27 Mar 2024 12:29:02 +0100 (CET) From: Ihor Radchenko To: Bruno Barbier Cc: emacs-orgmode , Jack Kamm , Matt Subject: Re: Pending contents in org documents (Re: Asynchronous blocks for everything (was Re: ...)) In-Reply-To: <6601b872.050a0220.31a67.5a55@mx.google.com> References: <87o7d0mm54.fsf@localhost> <875xz42rp9.fsf@localhost> <874jen8zec.fsf@gmail.com> <87o7cv9e80.fsf@localhost> <65c2875f.050a0220.caf6d.8291@mx.google.com> <18dae5cab1d.bf1c7563863897.4896289306902277373@excalamus.com> <65cfa0d8.050a0220.cb569.ce34@mx.google.com> <18dbe11968a.12c0800a31425096.5114791462107560324@excalamus.com> <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> Date: Wed, 27 Mar 2024 11:29:09 +0000 Message-ID: <87le63c3qy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=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.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-Migadu-Queue-Id: 8CEE9A96C X-Spam-Score: -8.05 X-Migadu-Spam-Score: -8.05 X-Migadu-Scanner: mx10.migadu.com X-TUID: TwMV3/GbbU+x Bruno Barbier writes: > I've pushed an update that should address most of your comments. Thanks! > I've found a better name: I'm now calling it a "lock". So I renamed > "PENREG" into "REGLOCK" as "region lock". The structure is now > `org-pending-reglock'. I slightly dislike short names and would prefer region-lock, but not a big deal - it is just my personal style preference. > I've renamed org-pending-ti-send-update to org-pending-send-update > (now that the task control is gone, the prefix becomes useless). I have a further request on interaction with penreg objects. I feel that it is not ideal that overlays associated with penreg objects cannot be fully controlled by the callers. In particular, I'd like to see some way to 1. Create penreg object without locking the region, so that scheduled-at time is not set immediately and status overlay is not displayed. Then, `org-pending-send-update' could send :schedule signal to perform actual lock. 2. Act on the outcome overlays - there is currently no way to remove them using penreg object. Maybe :cancel signal? Canceled penreg objects can then be garbage-collected from the manager. Also, the top-level commentary is getting incomplete and out-of-sync at this point. May you work towards more detailed top-level description of the library? This will make your ideas more explicit and make life easier for me during the further review (now, I have to guess what you meant by some parts of the code). >> HANLDER will be another object we may expose via something like >> (org-pending-handler (&key on-success-function on-cancel-function on-await on-insert-logs) ...) >> Then, PENREG will call appropriate handler function as needed. > > As the task-control is now gone: > - get/await is gone, > - cancel is now a hook/function of REGLOCK, > - insert-details is now a hook/function too of REGLOCK. >> ... >> Yes. Lexical context is implicit and harder to debug, while storing >> necessary data explicitly in the struct slots is more robust as we are >> very clear which context is intended to be captured. > > Done. Is there any reason why you hide the extra information behind :-alist filed? Why not directly adding extra fields with proper documentation? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at