From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id QOBfEfRdimZAeQAA62LTzQ:P1 (envelope-from ) for ; Sun, 07 Jul 2024 09:20:52 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id QOBfEfRdimZAeQAA62LTzQ (envelope-from ) for ; Sun, 07 Jul 2024 11:20:52 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Qj/0TgKj"; 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=1720343829; 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=m+ZMhtnqofc5Me+4ZJf5zRfM1bOFIfYxoMu56EwULe4=; b=Okfu7/tjlTkTY8tz2oMZ5tPpnJ03Z++ytgDoVytDJ7Vwyq9B8vRg6G/TBO5ZJoIPyb0xlb KthA6zaJx1ber12VHdmJIvtba3Ayzf42EsALztCkmXHCGUanMXqybl+TDazeSuVaAXM1CG 9bvmYWRwlZniKnItHnWvdtgMxVnE5CbcOSGvn2AiRyrng/xCMGn4xA21A7oRJwn+YEnvBp +e2pv2diHC0XBshbJjezOxzsFo3Q6k1yo17G5z/6xY+9iXpDiTU5eN0Gw6CzHum4Kh2+oh sZuMOEiusMZN+O9M2T//CYzjW/LerFMKwrZjxfgDMoRqj9fQCy8VWh4mxytHjA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="Qj/0TgKj"; 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=1720343829; a=rsa-sha256; cv=none; b=I0OhZy2Lt2hB/XelqoIvub2gM4ENBcCqfDz+cjs67OxANQgGr/9169nvjKiaK1Kc0RsR6j h5l6O34D9sJzoinWTqMWmOv6J7Q8gP/fsN6UhyIKedBv1e8sTnOwKHmopGVL9KZ23tauN+ xhCbO7C/jAEO7gVPXX4/Df7bdUWeff50uaHxlPcuaEDVYRwsu1stPsrnc31MyemcScfZN0 q+HeidTPQSAEzIBeV2UnrRzpuXYsxMtqQkNyL1ixAYPeJ7hRiYG+t0P27+mYBy8W+pntn0 4oegDASNc8WT4Mf8xC6iz1kdoJUN+UB64izl8rrOf8LLtA3CyfW9dK9znUKzEQ== 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 7D2B039463 for ; Sun, 7 Jul 2024 11:17:09 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQNzv-0007aN-W0; Sun, 07 Jul 2024 05:15:56 -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 1sQNzt-0007aB-MP for emacs-orgmode@gnu.org; Sun, 07 Jul 2024 05:15:53 -0400 Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQNzr-00038V-Gy for emacs-orgmode@gnu.org; Sun, 07 Jul 2024 05:15:53 -0400 Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2ebe785b234so29364281fa.1 for ; Sun, 07 Jul 2024 02:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720343749; x=1720948549; 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=m+ZMhtnqofc5Me+4ZJf5zRfM1bOFIfYxoMu56EwULe4=; b=Qj/0TgKj8XvVpaancXFpUaLiEA566L6y7pTkbLLGO21vBIiLSYIgeAbrANgVr1YXVe qBRErKz1wuY6Q1DXf6m1CUF9QV8WXDrXBC3CFUIZ2VtCCCDDIEjReZ1pKle3LtGx2M7V 3nEoDSvhusy8UHuvo5or1kjIZKDwM5k6TM3lanfe9Du5E7udoS/25Udm98rYuRzxHzcB 9AzKcryuPfyPHQ7C7g0jN87HrfLPoAKDfQAivz+grlDX0urW84L2dnkPlB/BPKS0EUAz ATGigWrkQYYcmN8WSATlEjUZj/+nxWZYnjfnUbpM6ZjawdhCOPlJinwIrSVHcnAFzfwv V47w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720343749; x=1720948549; 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=m+ZMhtnqofc5Me+4ZJf5zRfM1bOFIfYxoMu56EwULe4=; b=pnTSeMjprgbReJ0RZLNcCiOQxSgSNoRLk7b5fW/KG440PU0lPlpOHvouo1Dz2ez8n5 c/lJ8z0WOVt70ApZdAyjo+RsaJ2Hty6A6wdxU+nJseMufpzyBcv8lT1t6dRpF1eJPQ5D 5sfJ3ui9TRAKOCeB78lfQQIp7G8zzShWjUUSRE/tJ5cGvzakOTjuy5TISka3XFpirtTV W3bNJ8S9GXxPFs8/ZyXa3Vz2brDK43ERJ2lB0g7kRTsPJEAVNlRiLqY0XqfRVNF5yOjt G0kZ+Lmdhh1IFSR1s/+iacW1timZ3cLZ8b3rMWPz1GRLBlFot8eziTQiNYfBHGPUWOrF FhRw== X-Gm-Message-State: AOJu0YxGN6dZDhsFmehkSAtODEe2IZPqpKqDw50fApk1ZP5zygCJNHLi qmBXdCrUnfuCIWRD9/ezTPjFI/zyPQX9yGsexEr2IbyZmx7urQyGdM80kBFD X-Google-Smtp-Source: AGHT+IGR187N66JbfK50OJj4XCEZ2+6Q4TrVG1GA2brKzfA5CCtcWGuL7bO3+B2B+ODHIx46KJqvfA== X-Received: by 2002:a2e:301a:0:b0:2ec:5964:9c0d with SMTP id 38308e7fff4ca-2ee8ec47349mr58358041fa.0.1720343748667; Sun, 07 Jul 2024 02:15:48 -0700 (PDT) Received: from keynux.home.arpa. ([2a01:e0a:505:3460:1c18:688d:ece4:372e]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3679c9008b0sm8286057f8f.80.2024.07.07.02.15.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jul 2024 02:15:48 -0700 (PDT) Message-ID: <668a5cc4.df0a0220.11fdd.05c1@mx.google.com> Received: by keynux.home.arpa. (sSMTP sendmail emulation); Sun, 07 Jul 2024 11:15:46 +0200 From: Bruno Barbier To: Ihor Radchenko Cc: emacs-orgmode , Jack Kamm , Matt Subject: Re: Pending contents in org documents In-Reply-To: <87ed8xi688.fsf@localhost> References: <87o7d0mm54.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> <666d4779.050a0220.13efd.8a2d@mx.google.com> <87ed8xi688.fsf@localhost> Date: Sun, 07 Jul 2024 11:15:46 +0200 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=brubar.cs@gmail.com; helo=mail-lj1-x233.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-Migadu-Queue-Id: 7D2B039463 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.74 X-Spam-Score: -9.74 X-TUID: odysOFVHuCPM Hi Ihor, Ihor Radchenko writes: > Bruno Barbier writes: > >> 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. > > We may do what flycheck/flyspell do. Maybe fontifying not the whole > region, but at least the region part where the indication was placed. > > I really find the current behavior unintuitive even for experienced Emacs > users. I added 2 faces; org-pending is now using those faces for the whole outcome region. I personally don't like it and won't use it though :) >> 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'. > > Makes sense. Although, "display" part in the names is very confusing - > it sounds way too similar to `pre-redisplay-functions', which is > something entirely different. I've renamed them to pre-insert-outcome/post-insert-outcome. > What about removing org-pending-output-pre-display-function entirely (we > can add it later, if necessary) and renaming > org-pending-outcome-post-display-function to > `org-pending-on-outcome-functions' - an abnormal hook executed after > ON-OUTCOME action. I am using it, So, I would prefer to keep it :) The timing does matter, so I would prefer to keep being explicit about it (i.e. keep the pre/post prefix). These 2 functions define the implementation; they are not hooks. >>> 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 ? > > No. > > What I did is: > > 1. make repro > 2. Insert the example code from the top comment and uncomment it > 3. M-x eval-buffer > 4. *While regloc is active*, press C-x u > 5. Observe > > Debugger entered--Lisp error: (org-pending-error "Cannot modify a region containing pending content") > signal(org-pending-error ("Cannot modify a region containing pending content")) > (closure (t) (&rest _) (signal 'org-pending-error (list "Cannot modify a region containing pending content")))(1 81) > primitive-undo(1 ((1 . 81) (t . 0))) > undo-more(1) > undo(nil) > funcall-interactively(undo nil) > command-execute(undo) Thanks for the details. This is what is supposed to happen: the 'undo' is trying to erase the whole buffer content, but that buffer contains a reglock, thus, org-pending is explicitly interrupting that operation and raising a meaningful error instead. What other behaviour are you expecting here ? >>> 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 ? > > No, this problem is solved now. Perfect! Thanks for testing. (I removed the undo-boundary from org-pending; I moved it to the example) >>> 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. > > I still find it confusing. > Mostly because it is not clear if pressing "cancel" does anything. I added a header to make it clear that the info of the buffer is a snapshot at a given time. And, that the user needs to hit the usual key 'g' to revert the buffer. When clicking "Cancel", org-pending now aknowledges that the cancel request has been sent, using a message. >> The reglock is live in its buffer. > > What do you mean by that?? > How can reglock be active in the buffer that does not contain the locked > text? How can even have different state in different buffers? Sorry, I meant: The reglock displays its status, and keeps it up-to-date, in the buffer containing the locked content. >>> 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). > > Imagine that the process that locked the region hangs. As a user, I'd > like to be able to edit text in buffer if I see that the lock is taking > too long. How can I do it without closing the buffer? As a user, I would tell the process to hurry up, possibly throwing data away, as I need to edit that region (i.e. click "cancel"). Whoever started the process (that locked the region) should provide you a way to stop that process, by answering the cancel request and/or by providing another suitable interface. The default implementation will unlock the region immediately, completely disregarding any "process" and thus, will allow you to immediately edit the content. >>> 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 ? > > See my example above. For me, users should have access to "kill" - to > unlock the pending region and make sure that nothing unexpected happens > henceforth with that text. The unrelying Elisp that is creating the lock > should indeed be able to intercept such user request and process it, but > not refuse it, keeping the region locked. org-pending is just the messenger here. It doesn't start any "process" and it doesn't refuse anything, it fully cooperates :) Your "kill" definition looks like the current default "cancel" implementation. To avoid further confusion, I'm not using the word "kill" anymore about reglocks in org-pending. I added a function 'org-pending-unlock-NOW!' which unlock the region immediately. The uppercase "NOW!" emphasizes that it's not the "safe" way to unlock a region. >> 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. > > Yes. ok. I'll try to keep that in mind. Thanks. >> 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. > > You can use (message ...) instead. It is also fine. Good. Let's not promote the idea that raising popups from background jobs at unpredictable time is a good idea: I replaced 'warn' with 'message'. I've missed that you added a 1s sleep in the custom cancel function. This was wrong: the documentation says that this function must return *immediately* (see documentation of the field 'user-cancel-function'). I fixed it. I also restored the fact that, the outcome of a cancel request may be either a success or a failure. > >>> 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). > > Please link to that documentation somewhere in top comment, linking to > the defstruct. Maybe something like: > > Elisp programs can further alter various fields of REGLOCK object to > alter its behavior. See the docstrings in `org-pending-reglock'. Done. I've just pushed a new version. Thanks again for your patience and the many reviews. Bruno