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 IAt5BjUl/GVgeQEAqHPOHw:P1 (envelope-from ) for ; Thu, 21 Mar 2024 13:16:53 +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 IAt5BjUl/GVgeQEAqHPOHw (envelope-from ) for ; Thu, 21 Mar 2024 13:16:53 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=QXhl9JQH; 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=1711023413; 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=FdkQwkaCHyzh+qetzaBWtxGmbhu1cQzoGf1Y/+oJ2UE=; b=LF7SnVonZPX5yltJRX9YYGtIiTJMYuun/gttxKfntj2yS8FRDsZNucJ/qKsDGqdJpju4Gm YcN+yhJX7rpIK4BDbgUuyuUM2cpoLhrXCzD8RJZU70ejcOCpmsMN/8+oFDH+11Ae7PUDAu F1AJQ88slmpnW5S5j9vtZYwt0U7woPiFmGkBfdMTH1TZWeW+z1L1Nxe++7MBe2OwIGX5Uj VI3kCLyxg4jrch/UqzwXbHGhgLKu/oD1RqtBzaYTPrCS5IcOwMjW154g8WNrPa8Ey7By7t zQrO1zqdtA93EqzQXGf3cBHiAxo1RAFFuPBhf+un2vQFB7MzexU++MuxaMXkvg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=QXhl9JQH; 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=1711023413; a=rsa-sha256; cv=none; b=SZCVrfM1r2s9FOrXmBjEItuDGXIEWWoqlu94f5YLI90ZcvRzQj9l2/vGVszjUPpaq1pvcA Bz/3MzB7qCYPF5UOPaiIKPT6IUIWNCJN9swF6TKAYxwcDvJ27J4oU2amnMTNrDBOlANZ5K PjoH74/2YvsVyuibR9aK9IWWrCCViN+0nR+7p/UvkDU4ekkyjT5UGdhxrKXmGl0P4Hp6ab MW0bcQv8+hCQVqBbKLgzCYbeiogfNWbvycs/a+mvYfwS41LS+J/TyMfYrZkHFn8cpcv/up hRlah2vln4ukfQK9EROIRpQMG8bU3kyqkSYchrM7Nzzs575p7izyd/G4qSrtZw== 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 E2BAB42767 for ; Thu, 21 Mar 2024 13:16:52 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rnHL1-0001V4-5s; Thu, 21 Mar 2024 08:16:03 -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 1rnHKn-0001Tp-Je for emacs-orgmode@gnu.org; Thu, 21 Mar 2024 08:16:01 -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 1rnHKk-0007QV-C6 for emacs-orgmode@gnu.org; Thu, 21 Mar 2024 08:15:49 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 030AF240104 for ; Thu, 21 Mar 2024 13:15:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1711023343; bh=8lIbyFo61POWF6u1F/coeCLNTtICASAFM2YougDZxR8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=QXhl9JQHCcjvCr5pEBJkdEC6p8LM57pMBnjVjihEy8OW5ryc/sEoWkHVcA94lFLtq BwN4jrF2F9ZsmCWSB2q3TvIv44AfffGsjB+nB4S21TZWHdA1csk0qqrjluZJkkeHCv xYg+RqVGVyTQo4X8ceMt/ji5ztRMFd76xF4v6PqbYHu4db4q8004qRcpmXW2HM76m+ Ua3kzqVKYLK/2Om/Us6k8PVCLY9XcmEN6y33Ds5CXIehRZ1Xh2BjwT84NqORps2OZK Usk04OIqTyfX5KSrVvpc5Qn2Ca8aGei9jYEFFy0DYLkOFHEjLPfceoH4uDXf53mkUN 4mE1n9f+KUyuA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4V0ktw5Hzwz6v1y; Thu, 21 Mar 2024 13:15:36 +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: <65fc06c1.5d0a0220.0d53.efdc@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> <87plvpjj76.fsf@localhost> <65fc06c1.5d0a0220.0d53.efdc@mx.google.com> Date: Thu, 21 Mar 2024 12:15:29 +0000 Message-ID: <87frwjlr1a.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 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-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -8.02 X-Spam-Score: -8.02 X-Migadu-Queue-Id: E2BAB42767 X-TUID: XpPkh3A5Lc5I 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. >> 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. > > It's a constant. Calling a function looks more like we need to > recompute it each time, and, we could even change it. And > cl-defstruct writes the function for us. > > Do you prefer a manually written function ? Either a function or a clear indication in the docstring that ~virtual~ and ~region~ are connected and both read-only. 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. >> 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. > ... 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? > 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. 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". 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. 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. >> 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. >> 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. >> 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. >> Maybe we can hook into org-mode's fontification and display >> pending overlays in all the indirect buffers. > > Well ... "adding overlays in indirect buffers using font-lock" looks > like a very bumpy road to me ... (being very positive, assuming there > is even a road there ... :-) ). As jit-lock is explicitly disabled in > indirect buffers, I'm not even sure what it would technically mean. Right. font-lock is linked to text properties, so font-lock in indirect buffers is finicky (it relies upon text properties to function). We might try to brew something with `pre-redisplay-functions', but let's not dive into that rabbit hole for now. >> 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. > > Technically, the outcomes are overlays too; thus, they belong to > one buffer. > > If a user created an indirect buffer to focus on some source blocks, > he should expect to manage everything about them from that buffer. > ... that looks to me like a plausible explanation that matches the > technical limitations :-) This sounds like trying to fit (by force) expectations to technical limitations. As a user, I do not really manage everything from the same buffer and do not expect that Org mode expects me to do so :) But let's postpone indirect buffer discussion to later and focus on more high-level design first. > ... would prefer to put the no-clone-indirect > property to the org-mode personally :-) We cannot do it. People use indirect buffers with Org mode extensively. > Couldn't we just to forbid "pending regions" in indirect buffers ? > (pending regions don't exist today, so, that doesn't look that bad, at > least for now) This might be ok. But we should be prepared that "read-only" on the pending regions is not going to be reliable - the regions marked pending can be changed out of sight. >> 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) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at