From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id whWNIrRHbWY/yAAAe85BDQ:P1 (envelope-from ) for ; Sat, 15 Jun 2024 07:50:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id whWNIrRHbWY/yAAAe85BDQ (envelope-from ) for ; Sat, 15 Jun 2024 09:50:12 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DB5uqkIM; 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=1718437812; a=rsa-sha256; cv=none; b=beJxrfRqDBmoM8WsqJKX+Jo9GNxw9RdY98oiRGv7JiNIRwM+JaaFp4WO9LGpnfbHrMgo/Z FxUAu2ncMXtuaXj7zqjEx1Phnw9qeKyr2O1ZNPds1Ic35P0qjsr6vdbADQIdEb0J7iQ77k pO9Pa/aXWVRH7tfi2i5q4YozIzrOv6+r3h3d2bUp7kRjvBv4Zk2fVRO7TjMWdDSjqY8Did cM11l0Cg+LpPYuqOl4hOOLfIzT5s9ERauMuvIH3f+gcR93sO7Lc9mQnabbXMts1iN7mXTt 1SiK91bxh1z95p5c6NDgY6+18jL3UiKDmAXv5QMwqcxWkuHs7ee7u72aSFAohQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DB5uqkIM; 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=1718437812; 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=6T5qN6HSD4/gNlJS8JZWSdaLVFAS9fiodLxLCC9bzF4=; b=HLsYdD6gn4g9NlunIegtuVhzsxCKx50edh0ONkLSCrK7eQN06f4QmJacXawY4M4MfNZVi9 t3MZMN5HBSl3v5cGsJwEM5WzS34+U6Gs1edR8d80DCAHNR1RuLKjAqseneVwzgr24ro9vw zmUtKEBn4/KXnDWkbTZ/ED18vh66DON7sQTmhySan7NFU1XQzzzsrF8rQlQoVXkixxAIsg CdXjpcWChxJi8bvzWS+vqVt90FGRhYuwdIOHE81/6YhOtlTmEjavpJBe2VrSxcse3EJCGm WBhNogyXn1FBXO3Dwijq5hqkVp9o/LAyXJ5vobiYhFgUBOlryU9aJ2LBkU8QRA== 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 35E84331FC for ; Sat, 15 Jun 2024 09:50:12 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sIOA4-0007rv-7H; Sat, 15 Jun 2024 03:49: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 1sIOA2-0007rb-Gl for emacs-orgmode@gnu.org; Sat, 15 Jun 2024 03:49:18 -0400 Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sIOA0-0006Yy-Cr for emacs-orgmode@gnu.org; Sat, 15 Jun 2024 03:49:18 -0400 Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2ebeefb9a7fso33588591fa.0 for ; Sat, 15 Jun 2024 00:49:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718437754; x=1719042554; 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=6T5qN6HSD4/gNlJS8JZWSdaLVFAS9fiodLxLCC9bzF4=; b=DB5uqkIMJgw+oc8bO8pUAZxCfLFcTuM/iY+7WPJOMkj6SMnl+SQhc+ZrQ4J7v3rdN6 aIX23KA3LJcXf7w4U01Wcycjbmk8LmXBtk/RABHCAdzVxutDwsQ/5E84PnaPFjcaMJxA 36bw+Y9ZNVsFV4UGcUjFPM0WbJcI3rO04XZkdZZmh26eHm4s/wQ7AWqaR/4yyjnBfO8F 3jb8m6M7VOJ2ogUByIjPPNEmn+XZsMk29oe6Ky9YNOVxI27lsCW9hfw6weSGXdyNBP5k OarVHnqLWG/9fqjK5FKLqQwk5lkSeWzLp3sq6uHe0XrEVlv4q2FZ8jT/ZqwGfGfaUNyA 94Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718437754; x=1719042554; 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=6T5qN6HSD4/gNlJS8JZWSdaLVFAS9fiodLxLCC9bzF4=; b=XMLAN455JlsiD7yAq+K4Ae8FWN6L6wm/ZFS5EAbVsz3v+z2VEFYR6tICHAGb76Sxxv DSMpSFJFO//N7L3fDdJNVgv5rshkX8M026JJq7JdxcMxPoEEa959ruzjnwH8GLapvCQG k1vOLEj8ZltjbJxuma+rd+mC8Up2ajldCxE3ZdbNl4kUyAsnFZzkteitOxOwe7ZIe0Jc nhBZj65/dRS00a3fNxIuywkAM8mmmRL3CsIJx8dUr7yVbUXi8pccl/t97YnW96astrpC yTOPeCb2rVJuPtoe5uVg8DXsnl0u3/1/HCs1n/yGVeHpi2okVbmIrEXcne572zdyGqDT o1yA== X-Gm-Message-State: AOJu0Yxl+jvZz5Y9Si0I4C/600N2BKSlODet5C2DzDCcIV8sXO4dnSh9 L7yAbp+2VSM0t5XMRJEEQW0v0ogUjireHBmxAOr5RJ2k+wQAuP3eWmb3Gwcc X-Google-Smtp-Source: AGHT+IGzbRLBYBVGSAWl5P1FQpJd4EveyWLtxKIL5J5p4kB9V/fa7prPBTn4yqJEdFozfdJuYmgTPg== X-Received: by 2002:a2e:9e15:0:b0:2ea:e98e:4392 with SMTP id 38308e7fff4ca-2ec0e5d1888mr28829051fa.27.1718437753650; Sat, 15 Jun 2024 00:49:13 -0700 (PDT) Received: from keynux.home.arpa. ([2a01:e0a:505:3460:1c18:688d:ece4:372e]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-360750ad2c1sm6344687f8f.51.2024.06.15.00.49.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 15 Jun 2024 00:49:13 -0700 (PDT) Message-ID: <666d4779.050a0220.13efd.8a2d@mx.google.com> Received: by keynux.home.arpa. (sSMTP sendmail emulation); Sat, 15 Jun 2024 09:49:11 +0200 From: Bruno Barbier To: Ihor Radchenko Cc: emacs-orgmode , Jack Kamm , Matt Subject: Re: Pending contents in org documents In-Reply-To: <87plsyz3rn.fsf@localhost> References: <87o7d0mm54.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> <660ed63d.050a0220.36fdd.af23@mx.google.com> <87cyqwyvgw.fsf@localhost> <66225435.5d0a0220.f60e4.c590@mx.google.com> <87r0f02vq2.fsf@localhost> <664f6f54.050a0220.10342.b002@mx.google.com> <87o78vwnds.fsf@localhost> <6658cd1f.050a0220.f6605.de1a@mx.google.com> <87jzja71n7.fsf@localhost> <665abf9f.050a0220.d2a6e.ef6b@mx.google.com> <87plsyz3rn.fsf@localhost> Date: Sat, 15 Jun 2024 09:49:11 +0200 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::231; envelope-from=brubar.cs@gmail.com; helo=mail-lj1-x231.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, 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-Queue-Id: 35E84331FC X-Migadu-Scanner: mx12.migadu.com X-Migadu-Spam-Score: -9.68 X-Spam-Score: -9.68 X-TUID: O6INtKnqo1/A Hi Ihor, Ihor Radchenko writes: > Bruno Barbier writes: > > I have one suggestion though. You now do > > Use the function ON-OUTCOME to update the region with the outcome; if it > is nil, set it to the function `org-pending-on-outcome-replace'. > > However, `org-pending' is defined via `cl-defun', so you can instead > just put the default value for :on-outcome key and mention that it is > the default in the docstring. Then, you do not need to do any additional > checks in the function body; `cl-defun' will take care about assigning > the default value. Done. > I tried to run your example and have several observations: > > 1. On failure, it is not obvious that failure happened: > - The failure overlay disappear very quickly, and is not visible at > all if I happen to look elsewhere in the buffer. Maybe we can > simply keep it and remove the overlay on click The current method was to 'sit-for' 0.2 seconds; the new default is to do nothing (the overlay disappears immediately), but it's now configurable, see below. > - After failure, the "!" fringe indicator is visible, but it is not > obvious at all that user can click to get details > I first tried to click on the fringe itself to no avail. Then, I > randomly clicked on the text and got the description buffer; but > that was unexpected - the text I clicked did not have any > indication of its "clickability" - neither some kind of underline > face, nor an overlay or a mouse hint. I couldn't find a way to answer a click on a fringe. Is there a way? About how much to decorate, it depends on the user, I guess. For example, when org-pending is used for org babel, it should be obvious that one has to click on "#+RESULTS:". The current decoration is not the best for discoverability, indeed. But decorating the whole outcome region would be too much IMHO, and, it might interfer with other buffer fontifications. I've refactored the code and added two variables so that it's now configurable, see 'org-pending-outcome-pre-display-function' and 'org-pending-outcome-post-display-function'. I'll be happy to commit a patch that provide better defaults. > 2. I tried to do M-x undo while the reglock was active, and got an > error. I'd expect that undo would work, skipping the region. I'm not sure exactly what you did, nor which error you got. I've noticed that the hacks (to handle indirect buffers) were flagging the buffer as "modified" (using text properties). I've fixed that. Is the problem solved now ? > > 3. I tried M-x undo _after_ reglock was unlocked, and I got "TO REPLACE" > word highlighted. I did not expect it to be highlighted. I couldn't get that behavior, but the undo wasn't correct either. org-pending is now directly instrumenting the buffer-undo-list, and manually adding an undo-boundary. Do you still see your problem ? > 4. If I try to cancel the reglock, it does get canceled, but *Region > Lock* buffer is not updated - Live? still displays "yes Cancel". It's by design. The function `org-pending-describe-reglock' works like `describe-variable' and other similar functions. You need to revert the buffer (g) to update it. The reglock is live in its buffer. >>> What is the difference between "canceling" and "killing" the reglock? >>> Do they need to be separate? >> >> If you cut out, from the example, the part where they differ, they do >> look the same indeed :) >> >> I'm apparently failing to explain and document this correctly, as it >> looks like a recurring topic, sorry. >> >> Yes, they need to be separate as they are two different operations. >> >> - cancel: The *user* may request a *cancel*; it's a polite way to >> tell org-pending that the user doesn't care anymore about the >> outcome. A valid implementation is to ignore the user request. >> The default implementation is to unlock the region (sending a >> cancel :failure using 'org-pending-send-update'): it unlocks the >> region, ignoring why it was locked.. >> >> - kill: *Emacs* may have to *kill* some locks, because Emacs is >> killed, or the lock buffer is killed. org-pending will intercept >> the operations of this kind, ask the user to confirm the >> destruction, and, if confirmed, it will give a chance to the lock >> to do some cleanup by calling the 'before-kill-function'. > > Does it mean that clicking "cancel" does not guarantee that the region > will not be updated by the running process/timer? Yes, org-pending does not enforce that; and it should not, else it would forbid valid use cases of org-pending. A given user of org-pending may decide to garantuee that though (using a suitable function for :on-outcome). > In my eyes, there is no difference between user request and "kill". If > users asks things to stop, no modifications should be allowed to > the region. There is no relation between "kill" and "cancel". For "kill", *Emacs* is killing the owner of the lock; there is nothing to update. This is synchronous, immediate and definitive. For "cancel", the *user* is sending an asynchronous message to org-pending that it would be nice to release this particular lock sooner, if possible; that message implies that the user doesn't care about the outcome, but, if that outcome is available, then, just don't waste it: insert it in the document. Should I rename "kill" and "cancel" to something better ? >> I modified the example to rely on the reglock when possible (as >> opposed to values kept from the creation time). > > I tried to simplify your example as the following: > [...] > Nice! Thanks. I simplified the pcase. I switched back to the "my-" prefix. I'm not sure why you're using quoted lambdas, as if we were in 2011 ;) I guess it's so that this example works when copy/pasted to scratch for evaluation in a non lexical-binding buffer. I've left the 'warn' messages, but, I'm not sure we should. In my case, they are just killing my window configuration, even stealing the window where the lock itself was. > In the above, it is not fully clear for me what BEG and END arguments in > `org-pending-reglock-insert-details-function' mean and where the > insertion happens. I've removed '_start' and '_end' from the example: they are advanced features (see the documentation of the field insert-details-function). The insertion happens in the description buffer, at a position deemed suitable (the current implementation inserts it at the end of the buffer). Thanks! Bruno