From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 uOmMIa64AWY2JQEAqHPOHw:P1 (envelope-from ) for ; Mon, 25 Mar 2024 18:47:26 +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 uOmMIa64AWY2JQEAqHPOHw (envelope-from ) for ; Mon, 25 Mar 2024 18:47:26 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lBTWkrel; 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=1711388846; 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=MhiGTmL+nhryS1BgkVTms7R43mCuQIOlyPQtzeg/H3U=; b=OaFI6Nbcc2UdFSuGifzuT+O451C+1cZ+LrSwjwUvq8e47H17IDjVS5ju997YC0qQObOZ3q ngnDp5VLHErTUv3gxG3EbPTViELg2Eh4wLgehaID9G/IFYjOR1uud8T9Gn8S6zEjAb1fnf 80DrQuZxe2ryx9XjXUfrwAmJK2HgotMcDdAC0OBgKq0GsajNedovtFjQAjfdusBFNY/UcR 8Cb0hbK72xU0J/kxImOlKPnZ8GnZIJ8fiJmaabqpN1K5BCxUE5M390RgZipwwLXvOok0ON vofqgtMtbTJPY13EeRI7RGwTrinqjr9I1gez/lGrAMwoeNXfpplE3A9VOAlDHA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lBTWkrel; 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=1711388846; a=rsa-sha256; cv=none; b=mZPrOdmHo6dl2Gy0Tp06kzTyv8r3f2Ksb604S+ob11WgQ1qxCX31shWPpKnO08Rfx/aCXD gjK9srpvmTBzbUm1YpWSxzvQsuwhophTz85tyOvj2yisxLnwzkJuDodjdc9CLbzAUnMIb9 PqmEOLzPcJfEU+WrfuvhDyXQbEamUnzsxEfkBlP0nzLkC2Jbj0xPLOwC9Qc5ikBKQMJmwl 1FWtbCKD1swO1H2m83BTFWQdHHlphS5yiK7iyd13xMkzohwMHU4VHYf/FwLemxEVSnRY1u l10KdQPTYfzD8JiubBDrvgpxj3M+hzC1ejoVr4a/Xnx7QHpRHd0lu/5QYOJlpw== 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 2B395566BA for ; Mon, 25 Mar 2024 18:47:26 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rooP5-0002fT-UG; Mon, 25 Mar 2024 13:46:35 -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 1rooP1-0002eq-D5 for emacs-orgmode@gnu.org; Mon, 25 Mar 2024 13:46:32 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rooOz-0008K8-8D for emacs-orgmode@gnu.org; Mon, 25 Mar 2024 13:46:31 -0400 Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-33ed5b6bf59so3375085f8f.0 for ; Mon, 25 Mar 2024 10:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711388787; x=1711993587; 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=MhiGTmL+nhryS1BgkVTms7R43mCuQIOlyPQtzeg/H3U=; b=lBTWkrelckQ7U9xMSc2E8S6Wx6Hf4loKAfGmIZ5NAd1efidreEWczVoyZfUXXrBSS5 r3JEefUjNJKtmbWh+J30Hj0CiHa5/ZH6IJQAs9dTEMBAgwDUdnBg6o1Ck9NUiKr8TAsW OBUtWv5cG8fS92A6vIgI03Hbp7XeA5WU9uuMagVMsukfXGoRxmTUWXY1tsvQ7HEReajj sFWENwoiqRv5Z7XYhAIt6HaTJ2txT9EgbQcx2MaDXzXhNl1Z2JSdnYfDBxcrDVACFTiK GqVCiT059lrTUkvcaqd1gTswN3Fc1c6Rvo+J32r5+8dmagE7RgD6e3vXqPl3iMh2h4ot EYQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711388787; x=1711993587; 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=MhiGTmL+nhryS1BgkVTms7R43mCuQIOlyPQtzeg/H3U=; b=rKwwXg5PfgjOVn6v9T7d7eUC10NpaqJb7CPlhajTNHBdsR3njmQmJv0fWVDNnn2WQC ZN3vbFtCjeJ21o6CsVubSqFIDFD+Jhpr2W1eIeJJEP1WCq/Ka6poenjbAtkH8hktNcD5 2Ih0KC0RXN9fYYYF+RMzIpKn7QiqOpZi6ETzLjSLsY2FBkoeEYwIS52OyogkGRwAWJMw i4m4VL3C3OxFmM0Hj6iNGlFE6l7MW1VjttpvWMjuI12FO70TuAqsbUHVf48gfwohkjWI Tu3pORfPD44OG7J6+0epdtsrIJ2LJQx2soAnks+6/1D3SxQ8kFyhy/fTnK21O/6SD59M fVmw== X-Gm-Message-State: AOJu0Yw4TvKRigazS0k7KBpOUnX95B9Supx2okUyxbwc82ca+cwQgEFA NWQs5o/NM6vTvOmSkZT87K5x1X6N7P8Xl94BBnZK/q+IJBM3fT9M X-Google-Smtp-Source: AGHT+IHGiZQhqCok+M8L0a362A0GGxXk/WUGGFdt5Kt08etZxx+upegJBXQWpWuU+5ibrkdjN5gptw== X-Received: by 2002:a5d:688a:0:b0:33e:7133:ee31 with SMTP id h10-20020a5d688a000000b0033e7133ee31mr5871512wru.40.1711388786730; Mon, 25 Mar 2024 10:46:26 -0700 (PDT) Received: from keynux ([2a01:e0a:505:3460:1c18:688d:ece4:372e]) by smtp.gmail.com with ESMTPSA id bu14-20020a056000078e00b00341d2728e02sm1508773wrb.37.2024.03.25.10.46.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 Mar 2024 10:46:26 -0700 (PDT) Message-ID: <6601b872.050a0220.31a67.5a55@mx.google.com> Received: by keynux (sSMTP sendmail emulation); Mon, 25 Mar 2024 18:46:24 +0100 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: <87frwjlr1a.fsf@localhost> References: <87o7d0mm54.fsf@localhost> <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> <87plvpjj76.fsf@localhost> <65fc06c1.5d0a0220.0d53.efdc@mx.google.com> <87frwjlr1a.fsf@localhost> Date: Mon, 25 Mar 2024 18:46:24 +0100 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=brubar.cs@gmail.com; helo=mail-wr1-x431.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-Country: US X-Migadu-Flow: FLOW_IN X-Spam-Score: -9.62 X-Migadu-Queue-Id: 2B395566BA X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.62 X-TUID: yegLOWb+za7r Hi Ihor, Thanks for your review and detailed explanations. I've pushed an update that should address most of your comments. Let me answer point by point below. Ihor Radchenko writes: > Bruno Barbier writes: > >>> I feel that org-pending-penreg (org-pending-) is >>> redundant. Maybe better use org-pending-region? >> >> PENREG is the name of the structure; the "org-pending" is the >> mandatory library prefix; this mechanically gives the name. A PENDREG >> object is not a "region" in Emacs sense. >> >> Do you see a better name for the structure PENREG, so that it doesn't >> sound like a "region" ? > > Library prefix is also a part of the name and delivers useful > information. "org-pending-region" and "region" and not the same names. > > We make use of prefix semantic in various places: > - org-export-backend, implying not just "backend", but also "export" > - org-cite-processor, implying not just "processor", but also "cite" > - org-lint-checker - "org-lint" + "checker" > - org-element-deferred - "org-element" + "deferred" > > So, there is no need to duplicate information from the prefix - it is an > integral part of the struct name. Doing otherwise would go again the > existing naming in Org code base. Got it. Thanks for the explanation. 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'. >>> 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. >> [...] > Also, ~virtual~ field is unused. So, maybe we can even drop it > completely. We can always add new fields in future, if a need arises. The region is not allowed to be nil anymore. All "virtual" issues are solved! :) >>> 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)) >> >> The "source" is the region requesting the update. > > The docstring of `org-pending' states that it is a buffer position: > > The SOURCE is the buffer position that requested this pending region. Sorry. It was, yes. >> ... The pending region >> is the "target" of the update, i.e. the region that will be updated. >> >> >> For example, in DEMO_ONLY, with org-babel, these 2 regions are never >> the same: >> 1. the source is the source code block, >> 2. the target (pending region) is the result region. > > I am wondering why source must be a buffer position. > What if we want to mark a region pending for some task not associated > with a source? And why do we need to know the source at all? Good point. It was to allow the user to quickly jump to the source code block; I removed it from org-pending. >> 2. insert-details: If, and only if, the user decides to >> investigate what happened, Emacs will ask the task if it has any >> details to add, that might help the user (like exit-code for an >> OS process, stderr for an OS process or link to a log file, etc.) > > I have to say that I am confused about "insert-details" part. Mostly > because it is not per se connected to the associated task. It is rather > an additional handler used to provide debug information about the task > status and outcome. > AFAIU, it is conceptually very similar to HANDLE-RESULT function. You're right: it was confusing. It's now like a hook, that org-pending-describe-reglock will use. It should now be clearer that it's for "information purposes" only. > I think that rather than handing HANDLE-RESULT and also TASK-CONTROL, we > may reduce everything to a single "handler" object that will serve as a > way for PENREG to communicate back to Elisp. That way, we do not need to > have a concept of a "task". I removed the task-control, and, the concept of "task". HANDLE-RESULT is gone from org-pending. `org-pending' has a new keyword: :on-outcome that will allow to do anything, both on success and on failure. > Instead, it will be a familiar async API > with ability to (1) create (2) send signals to (3) receive signals from > PENREG object. > `org-pending' will be the entry point to create PENREG object. > > `org-pending-ti-send-update' (or maybe simply > `org-pending-send-update'?) will be a way to send data to PENREG object. > I've renamed org-pending-ti-send-update to org-pending-send-update (now that the task control is gone, the prefix becomes useless). > 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. >>> 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~? >> >> Yes ... I wanted a common prefix for the 3 functions that a "task" >> implementation is allowed to use: >> - org-pending-task-connect, >> - org-pending-task-send-update, >> - org-pending-task-not-implemented. >> >> It's not confusing if one ignores the common prefix :-) >> >> I've renamed all these functions from "org-pending-task-" to >> "org-pending-ti-" where "ti" stands for "task implementation". > > I still feel confused. As stated above, it might be a good idea to get > rid of the concept of "task" completely. Done. >>> 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~. >> >> That would require to manually capture (dump/load) the context that >> the sentinel closure is automatically capturing. >> >> Why would it be better ? Debugging purposes ? > > 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. >>> 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. >> >> I just tried to followe Emacs: a buffer owns its overlays; a pending >> region is (kind of) an overlay. Thus, a buffer owns its pending >> region. > > I do not think that it is a good analogy. > Not when we also mark the text read-only in all the indirect buffers > as well. > Let me state my idea differently - if some text in buffer is "pending", > it should be visible in all indirect buffers. Otherwise, as a user, I > may be confused why some parts of the buffer are read-only. You're describing the current implementation ... at least, what I tried to do :) With the current implementation, they should be clearly visible in all buffers, using the secondary-selection face. If they are not, it's because Org is explicitly removing some text properties. Oh, I see ... sorry: don't test indirect buffers with empty results, as Org is almost always removing custom faces on "#+RESULT:" (IIUC, Org doesn't comply with font-lock-face). [...] > But let's postpone indirect buffer discussion to later and focus on more > high-level design first. > ok. Thanks. [...] >>> 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. >> >> It's already there, no? >> >> If you click on any result (success or failure, inline block or not, >> even dynamic blocks), Emacs pops up a buffer with all the details >> (source, start, end, duration, stderr, etc.). The function >> `org-pending-describe-penreg' defines what is inserted. A given task is >> free to insert log, links, widgets, images, diffs, etc. (by providing >> the relevant :insert-details method). > > Your thinking also makes sense, if I use a different definition of > "failure" (in the context of PENREG, not in the context of exit code of > the attached process) org-pending now takes an :on-outcome callback: we can now decide what to do both on success and on failure, and insert things in the org document in all cases if needed. Let me know what you think about this new version, Thanks again for your help! Bruno