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 kNfHL4TWDmYzVAAAe85BDQ:P1 (envelope-from ) for ; Thu, 04 Apr 2024 18:34:13 +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 kNfHL4TWDmYzVAAAe85BDQ (envelope-from ) for ; Thu, 04 Apr 2024 18:34:12 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WFrdWS7I; dmarc=pass (policy=none) header.from=gmail.com; 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=1712248452; a=rsa-sha256; cv=none; b=Vk+AwDAetyrspgtaxKqswNJXVq78mvzJFFlmbFPicoV3qHm8dWaP04STO8tJpld2HAUXXu L01xA5Esar2eda0xEKCC+Zm9GmgDPApjc4gpZF9eV6kMKboU3ef52GRUVAm0EAcK6dl+A8 Nfigw30ntgstqJfMFBaq+eMI61Jw8fHuMOGIiNRMwWIFHS7p/r3oMRnuBli27qt039kE2m 9iF+VA1L+kQtC6Oii3+bMasrBrvATvufcDOz7YlAOrtN6koAzdLaMLvd27Fu4EINhCFeF0 hC7vRTW6x5lfCt1ORcdrGMfw0D8F+UuX85sgQUovrrtnaUuUNdRY84swTjRCPg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=WFrdWS7I; dmarc=pass (policy=none) header.from=gmail.com; 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=1712248452; 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=8KheeBtpe6gc5Xhg8p6wDxOJ0undDkvOdNUZLlQDFVM=; b=H1KyPG/ZVKwnkMav/0rbB+NtSEChnUip4wp8+7WPY+B/E61GORDOKHIt/vNGPk0GqoGrf2 DQgRq3gT+e0q6AwTgYgsn2VdD+/4JEdM+Tix5ew1v+tTNbZTbvBLsP02N+zQTnmVWsqZj5 DzdmzXbc0lHgxVwryzeQYHGDmS8GA44G4GoY3JNde/U1a8AcGF+lTXAdZpJGed4qo8m9Io CcfADSSeYRzvFLdFooCDrr5mkspDFObP5W71zXwsGPuzySEjwJXu9RgRW/uczrzt1K+4aU G7Du9q7r9Qg7TsvBs1Bd/8TvAS+xpNwspk5oFnROQ4Lrb6ynFhklqfHgs3PcUA== 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 6B5596C5AE for ; Thu, 4 Apr 2024 18:34:12 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rsQ1U-00053L-B0; Thu, 04 Apr 2024 12:33:08 -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 1rsQ1S-00052x-LK for emacs-orgmode@gnu.org; Thu, 04 Apr 2024 12:33:06 -0400 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rsQ1Q-0008H4-Jf for emacs-orgmode@gnu.org; Thu, 04 Apr 2024 12:33:06 -0400 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4162b8cb3e9so6856925e9.0 for ; Thu, 04 Apr 2024 09:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712248382; x=1712853182; 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=8KheeBtpe6gc5Xhg8p6wDxOJ0undDkvOdNUZLlQDFVM=; b=WFrdWS7I6Nekj4VbB/1BgwA2oSxh9eqsu+wCVO0KpIaEh8bMlk3nSrq5W3lCojpKUr QfGpy26gEMEiOq+pq96SQ2wpSVva+bGFwfyu36h5GRXFUpivNY4IEI0f2Luyax0LIuXn zBVedRttHEoPNbOpuhHLl6Lmogp6gb4OItq2JnL+CHQoZqCa8dQynvLADe3fMmXM995Z Wa8d3+yjVdOgjhiS/4QcCanusYWnc+4qCSqgvpenjCYS8c4UpiEbNjgCgtecqKASKINB csJpCR4Bxf6q1rvM0dLR/qKqt9gwDSHbeLqL+4iWLe6sWRrIfEJGu/8wOe7f0nljdZus BOeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712248382; x=1712853182; 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=8KheeBtpe6gc5Xhg8p6wDxOJ0undDkvOdNUZLlQDFVM=; b=UKt3+otu8MmM22ktOlLVpk8pVzt0qhkYAQCJc1N5fYZgAgt44KfKHPJhJ5gupQl9wV vTFeSD/9LD3O+NjYlmzfegEvgNHJi9Mv6Vs0JoA65eqcE06yIFMxshjRN1yC0Bk6l10G 1qscVkXg9NehMhgCuq/LazuilnQk97esGcqK+Y2vpjzPhGy7nRF+UD7/aFwm2y6Dz9FH QeDZwVnC/uQxezBgbZ5/2TdDiTtD9gYu29R4kXvGoBhpupGtu5xSPHkR1V/FKTAfDqX8 V+bG7u+t5l4w+YU0x3OGWoy4OK5mafAR/tfzBgtmbKG3xvJ7AwlyT4gmuEhkBUxbpuVX +rew== X-Gm-Message-State: AOJu0YzTl8VmKxGHIRbnAfqOLk06VG55iVrDLHtEA3KnybR791HbGMsf jWWj8B74cPCiucZq1a0rgdDWcPFSypbmIjBZDDgWJqbhWHubkpE/ X-Google-Smtp-Source: AGHT+IFULCC0m77lu0cdXAJjTIrJujdcRQaD3WCUtlkIr6Rphh0FGiYdqkAo+YD+PPBajqiClKJnuQ== X-Received: by 2002:a05:600c:1885:b0:414:8e02:e441 with SMTP id x5-20020a05600c188500b004148e02e441mr2940803wmp.13.1712248382234; Thu, 04 Apr 2024 09:33:02 -0700 (PDT) Received: from keynux ([2a01:e0a:505:3460:1c18:688d:ece4:372e]) by smtp.gmail.com with ESMTPSA id r5-20020a056000014500b00341dc343e21sm20438803wrx.65.2024.04.04.09.33.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 Apr 2024 09:33:01 -0700 (PDT) Message-ID: <660ed63d.050a0220.36fdd.af23@mx.google.com> Received: by keynux (sSMTP sendmail emulation); Thu, 04 Apr 2024 18:33:00 +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: <87le63c3qy.fsf@localhost> References: <87o7d0mm54.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> <87le63c3qy.fsf@localhost> Date: Thu, 04 Apr 2024 18:33:00 +0200 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=brubar.cs@gmail.com; helo=mail-wm1-x32a.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 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-Flow: FLOW_IN X-Migadu-Country: US X-Spam-Score: -8.15 X-Migadu-Queue-Id: 6B5596C5AE X-Migadu-Spam-Score: -8.15 X-Migadu-Scanner: mx10.migadu.com X-TUID: F2WfbDWHiMuD Ihor Radchenko writes: > 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. It's more about being one word than being short, and being a new and opaque word. REGLOCK is a new technical term; it's definition is the cl-defstruct. For normal use, this is just a black box to pass around. I'll probably switch to using just "lock". >> 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. I'm trying to limit the public API surface. I don't think we should leak that we are currently using a mix of overlays and text properties. > 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. Using the term "region" was confusing, sorry. That's why I switched to region "lock". I don't think there is a use to create a lock that doesn't lock. Also, that might be tricky to implement: `org-pending-send-update' is called asynchronously, from the user point of view. Having regions that suddenly become locked, independently of what the user is currently doing (if we implement the :schedule message), might be difficult. What use do you have in mind ? > 2. Act on the outcome overlays - there is currently no way to remove > them using penreg object. I've added a funcion `org-pending-delete-outcome-marks' to manually delete outcome marks that are in a given region. Else, everything is handled automatically. Once the outcome is known, the reglock is dead (not live-p). org-pending may leave outcome marks about the outcomes (outcome marks are optional). The outcome marks automatically disappear if the user remove the section, or, if a new lock is created for the same region. > Maybe :cancel signal? Canceled penreg > objects can then be garbage-collected from the manager. Cancel is handled by sending a failure message (see `org-pending-cancel'). It's customizable using the reglock field ~org-pending-reglock-user-cancel-function~, which can decide what to do (like kill a process) and which can send a better outcome. Standard 'cancel' leaves a failure outcome mark. I've added garbage collections of useless reglocks (success or failure): see `org-pending--mgr-garbage-collect'. > 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? Sorry. I tried hard to keep it in sync with all the modifications. I found it too much work, and, possibly overwhelming for the reader, to explain everything in the top-level "Commentary" section. That's why I deleted everything that wasn't mandatory to understand the core features. Everything should be documented as elisp documentation strings, following the documentation of `org-pending' and `org-pending-send-update', and, from code comments. > 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). Sorry, and thank you again for your time. I tried to improve the overall documentation. I hope it's going to be easier for you, and others. >>> 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? To hide them, indeed :) The API for 'get-status and 'get-live-p are `org-pending-reglock-status' and `org-pending-reglock-live-p' (they are read-only). The API for the new `useless-p' is `org-pending-reglock-useless-p' (it's read-only too). The fields anchor-ovl, region-ovl, on-outcome, set-status and creation-point are the dump of the closure context, so that org-pending doesn't rely anymore on a closure to handle updates; I've rewritten that recently. Nobody is supposed to use or change those values, except the update process. IMHO, dumping those as fields in the lock structure would be more confusing and fragile than keeping those out of sight. I could add comments when they are created/used in the code to help understand how they are used. I've added a new macro `org-pending-updating-region' that locks a region while executing its body. I've pushed a new version. The documentation in org-pending should now be in sync, sorry. Let me know what you think, Thanks, Bruno