From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>
Received: from mp0.migadu.com ([2001:41d0:303:e16b::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by ms8.migadu.com with LMTPS
	id kGSzObJ18WWAOgAAqHPOHw:P1
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Wed, 13 Mar 2024 10:45:23 +0100
Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by mp0.migadu.com with LMTPS
	id kGSzObJ18WWAOgAAqHPOHw
	(envelope-from <emacs-orgmode-bounces+larch=yhetil.org@gnu.org>)
	for <larch@yhetil.org>; Wed, 13 Mar 2024 10:45:23 +0100
X-Envelope-To: larch@yhetil.org
Authentication-Results: aspmx1.migadu.com;
	dkim=pass header.d=posteo.net header.s=2017 header.b=G5rqyk4K;
	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=1710323122;
	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=8sA3nwvcbQmHy41wiUnE6Zlz9F6kItBBN3rr3LoH7g8=;
	b=ailbiFEl28+Z54XJI97hJJdhW85QY6JqyXzXA579VS4qkZGgKhapfhqqVloH9xIlSU5SqN
	IpnB89KsBmmEdYiFP1Bh1NEj8O+1/m58eyduu6WORlrbDbdCVVE6oqsNcHEvrSQldp5NzA
	87WGV8afgoeqDnVFpCxAo2stIrYMUVIJobMJ2D2U3vcU2pQ+A+MbzZOttNv1JeQ1Z8xIZN
	FaZZfXGBc43rUtKZm0acO9GlWEyEFN2XWf4DNYUhFGx7nvW/8FVHeSVhUrwMTyz4UAxktF
	xQ7Jab7ziKmwaix1n22qGEVoQT5UVCdC4pYP4OiLTZcd13C4jI13PVPjWKDKbg==
ARC-Authentication-Results: i=1;
	aspmx1.migadu.com;
	dkim=pass header.d=posteo.net header.s=2017 header.b=G5rqyk4K;
	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=1710323122; a=rsa-sha256; cv=none;
	b=WYBTa3OuwRe+wFt4Bg4eePppc5ohyr53AKb9Hbm6Tu7uIm3nnO/0fjZD4pC6gH7OqE1rlZ
	v08xxsL276ezviWSdO73yuzVnZIJSUOrCX8wLowIR7GWdisZCyAig09l+aXecYrZYX/yot
	PBBrcMnWguuesirBYkzyNSPrfUiIM5vy/xGvn0NTDPr1TYCNl+b8kVbnCVgtLvu3WDdDvg
	Kb8vJ/zpxhzKW1OebyvGsrT0sHYjvuxe2v4gwbMLn5SSpncTD39c9sss70rR7c6UF+R5cg
	BoaWpAcRtqb2IGeadOEqMsQLv3nYP/tF9bRGtn0dD9//tn+6pRO26BdG2+pDwQ==
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 9BA6515C15
	for <larch@yhetil.org>; Wed, 13 Mar 2024 10:45:22 +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 1rkLA0-0002t6-2A; Wed, 13 Mar 2024 05:44:32 -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 <yantar92@posteo.net>)
 id 1rkL9y-0002sw-Pn
 for emacs-orgmode@gnu.org; Wed, 13 Mar 2024 05:44:30 -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 <yantar92@posteo.net>)
 id 1rkL9v-0002V0-Jm
 for emacs-orgmode@gnu.org; Wed, 13 Mar 2024 05:44:30 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 59C7B240101
 for <emacs-orgmode@gnu.org>; Wed, 13 Mar 2024 10:44:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1710323065; bh=P63CerJrKAXdlFY9kGggKbnONwdDnrAXtUhCHqzReEU=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:
 From;
 b=G5rqyk4KjyehgXZIlLsbfsVV4EByUexiry/RiKUDSWdv3zcFTiv2RLwaRciUhlCfF
 Xnp1m4BxvBgHXBYKaiM8C1JbFky18ogPQxynvCTre6Du+geoQhpaxqzCR1J2aRTAIx
 O1F2cvUviSiaV024i7vA7vYoNDLa+rx5tDHQz6q5nKUiApzF+5Zre1krqqfxuO4wwI
 jl0E8O9UwH2vsZNtFY8DYc/yB9Wk4fo90mGKO0jRMVb6ogcViw9mGAVjXJhHC+9EF9
 fiqwVSORhGbzv0RNNUw117DnDTnEIEqMFidJ7tTt7zNdRNbYMRCNTNp6ACMuPlDv/W
 NWlZcqtriuIhA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4Tvlw80yvSz6tm8;
 Wed, 13 Mar 2024 10:44:23 +0100 (CET)
From: Ihor Radchenko <yantar92@posteo.net>
To: Bruno Barbier <brubar.cs@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>, Jack Kamm <jackkamm@gmail.com>,
 Matt <matt@excalamus.com>
Subject: Re: Pending contents in org documents (Re: Asynchronous blocks for
 everything (was Re: ...))
In-Reply-To: <65eb1e60.050a0220.337b2.a0f4@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>
Date: Wed, 13 Mar 2024 09:48:32 +0000
Message-ID: <87frwuxy1b.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_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." <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>
Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org
X-Migadu-Flow: FLOW_IN
X-Migadu-Country: US
X-Migadu-Spam-Score: -7.99
X-Spam-Score: -7.99
X-Migadu-Queue-Id: 9BA6515C15
X-Migadu-Scanner: mx13.migadu.com
X-TUID: EtSO8OFQXe87

Bruno Barbier <brubar.cs@gmail.com> writes:

>> While reading the library header and `org-pending' docstring (btw, it
>> should probably be a separate library, not a part of org-macs),
>
> I was feeling more and more like squatting the wrong file :-)
>
> Would "lisp/org-pending.el" be OK ?  Or do you see a better place/name ?

org-pending sounds fine. Maybe org-pending-text to be more explicit.

>> More or less, org-pending implements Elisp asynchronous process control,
>> but the processes are associated with region, not the whole buffer.
>> Hence, I feel that we should adopt terminology similar to the existing
>> terminology for processes - process filters, process sentinels, sending
>> signals to processes, etc. And similar API.
>
> The current `org-pending' doesn't know what a process is, or a thread.
> The job of org-pending is only to let Emacs know that a given region
> will be updated at some point later (much like what
> `org-edit-src-code' does, when a source block is being edited
> manually).

> I've re-read the Elisp manual about asynchronous processes.  The only
> thing that seemed obvious to me, was to replace "feedbacks-handler"
> with "sentinel".  I also tried to simplify things and use REGION
> instead of CONTENT where it make sense.  Thanks.

> Do you see something else ?

Similar to process API, your library provides means to interact with
process associated with the pending text - create them (40.4 Creating an
Asynchronous Process), handle feedback (40.9.2 Process Filter
Functions), handle on-done/fail/etc (40.10 Sentinels: Detecting Process
Status Changes), kill/cancel execution (40.5 Deleting Processes, 40.8
Sending Signals to Processes), insert-log (strerr in Emacs processes)
list pending (40.6 Process Information), org-pending-on-kill-buffer
(40.11 Querying Before Exit), get information (`process-attributes',
40.12 Accessing Other Processes)

I simply went across 40 Processes section of Elisp manual and I see
parallels for pretty much every subsection; but the terminology _and
API_ are different.

>> Also, I am not sure if I like the idea of exposing raw PINFO alist and
>> mutating it. In particular, I have doubts about mutating CONTENT.
>> What we might do instead is implement PINFO as struct with custom
>> accessors/setters.
>
> I went for this simple alist because it's more flexible (easy to add new
> bindings) and less code than using a struct.  And Org already uses lists
> like this (params, info, etc.).  Mutating CONTENT (or other essential
> data) would be a very bad idea indeed; but it's like that for pretty
> much everything with elisp.
>
> I'm OK to rewrite it using a cl-defstruct (to be honnest, I just
> flipped a coin to decide between a struct or an alist :) ).

I think that I need to elaborate.
It is not necessarily a matter of alist vs. struct, but more about the
API. I do not like the idea of mutating the alist entries directly. I'd
rather expose an API to work with "pending" as an opaque object - send
signals to it, get status, etc.

struct is slightly better here because it automatically defines setters
and getters for all the slots without a need to write extra boilerplate
code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>