From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id ABowGrqwbmaCLwEAe85BDQ:P1 (envelope-from ) for ; Sun, 16 Jun 2024 09:30:34 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id ABowGrqwbmaCLwEAe85BDQ (envelope-from ) for ; Sun, 16 Jun 2024 11:30:34 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=grsEVWCp; dmarc=pass (policy=none) header.from=posteo.net; 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=1718530234; 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=I7Bk+Zj8JTQansw4eAoowSomliTrHoOStOg4lAr0btM=; b=KbPo71bplcZaVblhZvLXDMmFvgVGa8fYnsDYWN5WGXlbVC635FCtPhJpJxCsBvmD+TN40h 4SbPipnmmp/Ukn02/G6m8o+uHPCl7TPv2h52lSWB+ucvRbyY1wNZ+35InL431zx0hw+tbG bKw9d0kgCHzXl4djbcxWTefm02u0cSg3TFvViGDwDW52rbmb3ymNHv9HUfTcHkQpbOIu9D 8khPT4B3bN5IyO36fwpzNI+wsgZB93t3nt+NLxAooDoeWRt79ITFnZIIeMxU6lKgUEI0h/ DFvNMtaPcy6Jt9kj1+83XMO8gEpfiEwd7VWWusHTZY3wAEmyp7OmMCgtRZv7Tw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1718530234; a=rsa-sha256; cv=none; b=c6RcIxjojrggmoL0A/IaoBMmmbNtqJapUh9g/bR4bOZBPGnZbQ6YsAnuhTZxHr1aXpaqXe K5E56wZ7f6xI4vuyIqHoJ3Cp9u/CQY3d7Q9Sjq+M6Bm6yiR4OZyMnDfTZ4jhv2WJxN+j2k i16xi8+tqO1S3x/a22myB/WH9NywQJa2nUZTyaQ9oAKpgtXBmlRR+XF/045FQiLEbPHRIn J3XpdW8o1RkoLCdeQRLEy6mBTFHvs52bkblkscLBoOyIVxiy86mr+xFfUIqnA9NOAoyowS 1fCi8cS+DHBTIZc0XZvof0ht6nnz8zTXS5CRH8rO91MDYX4VqGRPChRu0UolAw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=grsEVWCp; dmarc=pass (policy=none) header.from=posteo.net; 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" 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 2135066FC9 for ; Sun, 16 Jun 2024 11:30:34 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sImCz-0000SW-Td; Sun, 16 Jun 2024 05:29:57 -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 1sImCx-0000Qc-SG for emacs-orgmode@gnu.org; Sun, 16 Jun 2024 05:29:55 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sImCu-0002K0-Tk for emacs-orgmode@gnu.org; Sun, 16 Jun 2024 05:29:55 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id CA745240028 for ; Sun, 16 Jun 2024 11:29:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1718530190; bh=1685cfvoPNtZLKn6oivGyj625oY3z8H8MQIE5IuuObc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=grsEVWCpxMZz1Zt5ME7k6URs1hPHlCaUdJGRZ8suKlSYfFEVifCPFisPa4SYqCHuJ +1BdB5Af5cCNyBTycxFKsv4WONcwPxEg/cIidify7TIOlBMd+/YiRqU7xq6wXOuyWC m1xAjBPbhXRgqXvf9MVjReiitLueCYuJNHr2WL6EvXYILyOFYbz9Fo9FQ/KLBiho9S HbPuzkijZjdoGh4bbTlEB6pyOnB6xotU6+do6g/oHnsYjlkwxzJKaHFDMkqGB/dn84 FiEYJaiNZSlj4cCz5LbSR7tvzKaOUYjSi1G6h9lmH0lpFmJd721YE0eQnAsrHzAkY0 BiUuVcY+2FGXQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4W275V1mqFz6twc; Sun, 16 Jun 2024 11:29:50 +0200 (CEST) From: Ihor Radchenko To: Bruno Barbier Cc: emacs-orgmode , Jack Kamm , Matt Subject: Re: Pending contents in org documents In-Reply-To: <666d4779.050a0220.13efd.8a2d@mx.google.com> References: <87o7d0mm54.fsf@localhost> <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> <666d4779.050a0220.13efd.8a2d@mx.google.com> Date: Sun, 16 Jun 2024 09:31:35 +0000 Message-ID: <87ed8xi688.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -5.07 X-Spam-Score: -5.07 X-Migadu-Queue-Id: 2135066FC9 X-Migadu-Scanner: mx11.migadu.com X-TUID: 7IzU4uKWf2wE Bruno Barbier writes: >> - 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? Well. I do not know a way either :) > 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'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. 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. >> 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) >> 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. >> 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. > 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? >> 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? >> 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. > 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. > 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. >> 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'. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at