From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id COseFli5+mX5BAEAqHPOHw:P1 (envelope-from ) for ; Wed, 20 Mar 2024 11:24:24 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id COseFli5+mX5BAEAqHPOHw (envelope-from ) for ; Wed, 20 Mar 2024 11:24:24 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=VKs4WhNP; dmarc=pass (policy=none) header.from=posteo.net; 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1710930264; 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=dkAxF696ivM0LOlr0HxyNRLmzVmJtyTXzXTfkk99UBc=; b=vDmvmCFz7tp90IhztPTHYTV0dq+iTPLxBuk0rDMjWsPlkmjTgBUUOPP8aPvGZbHnLzUXYt LNEUIbghsb6y6KVsHitT8rPxkzC+gTTZO5OD6dj/7zxb5T5spbKU5VLr/yH7hKmqxdfL3i nx3gQDOnoAD6K6Pa9ThmY80gmwl8VrD3NLbIlHeF8PdfyNvPBdXj2KpHOnUE8OMt+HKyvk ulqCq8ErPry/aGgQCSx1gMhXdYVZGIlKM0aBNI0CFQrtkG07BBfBBOjWt+xmtdyc9hEjvk gfWyuBLzfIWRYqLb1ohRFhITdCi2Rh17crHFyXv3RZIwUTjsM706h2EQEFNuGg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=VKs4WhNP; dmarc=pass (policy=none) header.from=posteo.net; 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=1710930264; a=rsa-sha256; cv=none; b=PLW/cGEqbVOPpkMWHbtShs8AOm56AyHO3dznmX/0tFcl4HSs42opVGqg96emLfvppnb3AO Zquvzh0E64V8o9aC3uecMU2RHA3dFcYIIMYsLU8oX7GxtlRGwCNmTgaJutwou6+ThNplob kDgmwtmsd/4OkpxXynJtKA/PijSicOjkLg0VFxrKuUswIYS4jEZl24p6ngTywAqsoMT8W3 6MogqADmWZmWvw3m/ZoS8ZeIkBA17hXcgfiViv6RxiPBLa8FJZ5e4HtOomJgyU/Upj/bCo FNsMQrjY0gYybMGjlfUIQhNCdbp57JHRgyA9ixao+ldgLh5EvaJFiB61NhnrwA== 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 7C8AC59D4A for ; Wed, 20 Mar 2024 11:24:23 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmt6O-00033F-TZ; Wed, 20 Mar 2024 06:23:20 -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 1rmt6M-000337-O0 for emacs-orgmode@gnu.org; Wed, 20 Mar 2024 06:23:18 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmt6K-0001av-Cc for emacs-orgmode@gnu.org; Wed, 20 Mar 2024 06:23:18 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4E043240104 for ; Wed, 20 Mar 2024 11:23:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1710930194; bh=gPhgF+a6zLJDJ4tyxCDa+m5dx47zsVM+qId30600940=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=VKs4WhNPTRmLh3zuUtXcTnbHoGAsW0ZduU3UoClenWvHa7d+Filw/O723u0cAfwmD rh9s0lVY/mPUjOygr/Bbxy89mT8giijp60QklLN0noPaYhTCQQPKdZTgXfGvSN7SA6 EWr/dHJAfwgiLyqnOq2Hx9h/MFbXCsLvdRL5a8ljRAezpAcqLFk0EtCqFhoGFdXG0o mEnsc6T3Y8r1ykiJD4zpzVKmvsxsfyUjY5d2aMFKlWgxRo8Jdg45L03sYWVsobnnNt 3CrN/yzfbJwMqfblWmZFB5eM9CumXwvflu7OX/Jctv8WdhoROvWdSjC8S1WIgL1Fi9 iwBBwU/gOtMsg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4V04Rj2dw6z6txb; Wed, 20 Mar 2024 11:23:13 +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: <65f95bf2.050a0220.6d051.c8b1@mx.google.com> References: <87o7d0mm54.fsf@localhost> <65bbb108.050a0220.b60fd.6790@mx.google.com> <87jznm8hcu.fsf@gmail.com> <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> Date: Wed, 20 Mar 2024 10:23:09 +0000 Message-ID: <87plvpjj76.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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-Migadu-Spam-Score: -8.01 X-Spam-Score: -8.01 X-Migadu-Queue-Id: 7C8AC59D4A X-Migadu-Scanner: mx11.migadu.com X-TUID: 85nh+RKUJYKb Bruno Barbier writes: > I rewrote the API, rename many things, moved the code around and > sorted everything into heading/subheading sections. This is hopefully > less confusing and a lot simpler; and the documentation hopefully > explains better how to use it. Thanks! It does look more clear. > The updated section "Commentary", in org-pending, describes the 3 steps > that are needed to mark and use a pending region: a PENREG (I've renamed > "PINFO" to "PENREG", for PENding REGion, more specific). I feel that org-pending-penreg (org-pending-) is redundant. Maybe better use org-pending-region? > WDYT of this version ? Comments on org-pending-pendreg struct: 1. It is not clear why you need a separate ~virtual~ field. When ~region~ is nil it already implies that the pending region is virtual. 2. ~id~ field is semi-internal and assumed to be a number. Maybe we can do something more similar to Emacs process API: (make-process &rest ARGS) ... :name NAME -- NAME is name for process. It is modified if necessary to make it unique. We can replace id with human-readable name that can also be supplied when creating a pending region 3. ~source~ field must match the ~region~ marker buffer. Then, why do we need this field at all? May as well just use (marker-buffer (car region)) On the design of ~org-pending~ and ~org-pending-task-connect~: 1. I feel confused about the overall design of the interaction between pending region and the associated task. Functions like ~org-pending-task-send-update~ imply that pending region is rather decoupled from from associated task and the task should arrange manually for sending updates to the pending region object. On the other hand, there is ~task-connection~ that is used to kill associated task/process or to "await" for it. This time, pending region is strongly coupled with the task, killing it upon deleting the pending region. I think that we need more (optional) coupling between pending region and the associated task. We should be able to get more information about the task from pending region side - get logs, current status, exit status, etc. More specifically, I think that we need (1) allow to pass task as an argument for ~org-pending~. (2) In ~org-pending-task-connect~, we should allow the task to be a process or timer object. Then, we can automatically arrange retrieving process/timer status from the task: Use process sentinel (maybe, modifying existing via ~add-function~) to arrange process status changes to be automatically submitted to the pending region; Get log updates via process filter Kill process via ~kill-process~ Similar for timers. If the argument to ~org-pending-task-connect~ is a lambda, we can use the current approach you implemented on the branch. 2. ~org-pending-task-send-update~ name is confusing - it reads as if we send an update _to_ the task. Maybe better ~org-pending-region-update~? Then, we might even drop ~-sentinel~ field in org-pending-penreg object and instead implement that hard-coded ~update~ lambda from ~org-pending~ as a part of ~org-pending-region-update~. 3. I feel that different handling of "owner" and indirect buffers is not right. From the user perspective, it does not matter whether we run an src block from one or another indirect buffers - it makes sense to see the status in all the indirect org-mode buffers. Maybe we can hook into org-mode's fontification and display pending overlays in all the indirect buffers. Further, it is very confusing that running src block twice from the same buffer is not the same as running the same src block from one buffer and then from another indirect buffer. The current implementation of ~remove-previous-overlays~ makes such distinction for reasons I do not understand. 4. I have questions about ~handle-result~ argument in ~org-pending~. It is only called on success, but I can easily see that we need to handle things specially on failure as well. For example, insert stderr or perform other actions like displaying some buffer. Or we may even hook some special action to clicking on status overlay. For example, clicking on "failure" status overlay may raise stderr log. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at