From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:1008:1e59::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id YPLaE/C/WmbDSwEAA41jLg (envelope-from ) for ; Sat, 01 Jun 2024 08:30:08 +0200 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 mPG6EPC/WmYgsgAA62LTzQ (envelope-from ) for ; Sat, 01 Jun 2024 08:30:08 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JML0p6zc; 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=1717223408; 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=EIInS/SgeU3dF7Tn+TvnfRVy2zkCjbsjM9A+TDpwVrU=; b=l/kVnXP6Xwn7LwVW2bPUCpAqJjB4FcbHCcj6mAZyuDSbQ6cL9hJnrqcHD61UmPcbfo6AZ4 9iSS64bqyuuMi3sZYjCVwlaqvgMd6B5g5sZ903oIn93RTpHaDTeIFQl4S0FjPDqX+41kee q0UlEHoyp+/m04lESDu0lmtHQTeBs9AJM18N7VvYtFdrEfW/xc6/o7TQbfxp6eGdpJOhNr RZc5UG3SYmPNTEh0VcLGBY+r/EsEolW2ndALruC+J7mQ2jMO67f/Eu4SEhIVLwZgZJ248P CAVNDHZ12p2hylyA4HaOhPJXz9sTTDvGeMtTroHdxLKRPGS7f9Qp/R8G50w3KQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=JML0p6zc; 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=1717223408; a=rsa-sha256; cv=none; b=EgFLwr4jHyxYaNWUo2VcIp8ZP3vAnJKPSr2SC++ZN6Jzbt759IEyNQmoX7qAf6HngepkeM L6roUSGpRvyhWFwoTQJ2ZRekVw94grYjqyyBrg9tAVp17MxC3xCiBXMrsWtks9AvzGkYP8 cprBskLbZsUTHl7OJf9tUBQ+7DglKNxjCDS8qkjDDJY4tjmKtXc2AjhBVFIaq7ZKiT9H4F dY2Tny+D2TCLlY7JTJY3k5Peb2gPOgpUO43gFkV9t3Oa1WmxEgQv0VDQmColW5QuY3UF6W +NzmnRP9e0+6u2cnuezHwfV4lEWtQ1kHeNDm6FMTLqvCJedfC1z+5yaER9gdDQ== 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 F3A2F148E6 for ; Sat, 1 Jun 2024 08:30:07 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sDIEY-0005l9-Mg; Sat, 01 Jun 2024 02:28:54 -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 1sDIEX-0005kv-9n for emacs-orgmode@gnu.org; Sat, 01 Jun 2024 02:28:53 -0400 Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sDIEU-0002Jm-VO for emacs-orgmode@gnu.org; Sat, 01 Jun 2024 02:28:52 -0400 Received: by mail-lj1-x229.google.com with SMTP id 38308e7fff4ca-2ea903cd11bso22834071fa.1 for ; Fri, 31 May 2024 23:28:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717223328; x=1717828128; 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=EIInS/SgeU3dF7Tn+TvnfRVy2zkCjbsjM9A+TDpwVrU=; b=JML0p6zcmB7eEVi+j/c9/kFW8EeXV5j2Gb78OIhSx0EGvtUdatdCvDHDw77TSbv8ik YB7kvawVQUPzdXue+ovaKt3QgtE/U1MLvqcBcTs1vjr4HRQEc8KSM8JXko0GpeSAgaRC vA1knfKsVgjmPMfdzVtxOnBk5ifbl/xYuq6fdnalTCRdBsLczvtKEO/hPS/jqJwPXY6T 4zo35P510IfOrlaodj0J9JFSBgrb0nSkjCVxI2kmZP1z5pfhCKLiunFwPt+jJESLdPYt qkFQBr+8KoVmpegwCE68INnMhR5Io16PQLxM2AExvUN2DhAzye55DDRu2LchkDHjKMi4 RLXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717223328; x=1717828128; 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=EIInS/SgeU3dF7Tn+TvnfRVy2zkCjbsjM9A+TDpwVrU=; b=qQyOA+acjPzTKQPsVEjFcGZRtUk27DKWlTDlT6ZNcK5k35IiOPJHRjZr0iYeEvnAmB PtOfsEp6uUxPlTqexFX8OS2cFDMbg9o+2ZzUK6uDkR61u61ZRSTkfbqc7mfUwQTsHdLT LuSd++rpFZT8EqfWITG1QFfcAKGFRoN643TXrvNQLqp1wvx1W++jEVaG+KoNU2JE8P0S JLXezEGowl7fp2C7p8OtrkpETB8ce7MertK7gFyduZ16kMPmqxLQ4Sm7K7j4iulQOSLj MR8UQ4ouS8ohaC77gvdWCaOJjU6M7QmP8iwEzm2ku05WRQjYcdRN4nfA4K22jTvhuOgp ERhw== X-Gm-Message-State: AOJu0YzqL7TgN3qmNoYH6qd5Z86ZkkqyjnvTB4JvUptIIRDRe2dCoRlW 4SCVs8mXOGeSvo6z/txoEDAXeZtoYuLVv7V7qUWy4J9AFEGAds3t X-Google-Smtp-Source: AGHT+IE+sfTOq+hg2b7a3v71aK4H8EZsmSA03Iv0hx6FtW4EMGDzjqgM6SDDS8xFdCuYQGxIBdAaLg== X-Received: by 2002:a2e:a583:0:b0:2ea:82cf:ec5b with SMTP id 38308e7fff4ca-2ea951e4a03mr36466411fa.37.1717223328167; Fri, 31 May 2024 23:28:48 -0700 (PDT) Received: from keynux.home.arpa. ([2a01:e0a:505:3460:1c18:688d:ece4:372e]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4212709d336sm75176355e9.37.2024.05.31.23.28.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 May 2024 23:28:47 -0700 (PDT) Message-ID: <665abf9f.050a0220.d2a6e.ef6b@mx.google.com> Received: by keynux.home.arpa. (sSMTP sendmail emulation); Sat, 01 Jun 2024 08:28:46 +0200 From: Bruno Barbier To: Ihor Radchenko Cc: emacs-orgmode , Jack Kamm , Matt Subject: Re: Pending contents in org documents In-Reply-To: <87jzja71n7.fsf@localhost> References: <87o7d0mm54.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> <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> Date: Sat, 01 Jun 2024 08:28:45 +0200 MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::229; envelope-from=brubar.cs@gmail.com; helo=mail-lj1-x229.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-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.67 X-Spam-Score: -9.67 X-Migadu-Queue-Id: F3A2F148E6 X-Migadu-Scanner: mx13.migadu.com X-TUID: UtYuKnbpB5b8 Ihor Radchenko writes: > Bruno Barbier writes: > >>>> ;; (org-pending-send-update my-rlock (list :progress "Not ready yet.")) >>>> ;; (org-pending-send-update my-rlock (list :progress "Coming soon.")) >>> >>> Should the progress message always be a string? >> >> No. It may currently be any data. org-pending will format it as a >> string that fits on one line. > > Please say this in the docstring of `org-pending-send-update'. Done. >>>> ;; (org-pending-send-update my-rlock (list :success 1)) >>> >>> What will org-pending do with :success 1? Will it replace region with >>> "1" or will it do something else? >> >> That's the job on ON-OUTCOME to convert/format/append/prepend/replace >> some content if needed, on :success and/or on :failure. > > Fair. Although, it feels like a common use case to replace the region > with :success value. Maybe the library should provide some ready-to-use > functions that can be used as the value of :on-outcome. I've recycled the old function used by `org-pending-user-edit', improved it and made it the default :on-outcome handler: see `org-pending-on-outcome-replace'. I've simplified the example accordingly, removing the custom :on-outcome. I don't know any safe way to replace some text, but, I hope that will be a good enough default. >>> It would be nice to have an example that will also send a signal to >>> process, as it is probably the most commonly used way to utilize >>> org-pending. >> >> For my many use cases, that would always be a mistake to kill the >> process: an OS process is always in charge of many locks. >> >> More importantly, to find a self-contained working readable example >> might be a challenge. >> >> We could add a function 'org-pending-shell-command-on-region' in >> org-pending, that could be used as an implementation example, like >> `org-pending-user-edit', `org-babel-execute-src-block', etc. > > Yes, having pre-cooked wrappers for `org-pending' or pre-defined values > for :on-outcome/:befire-kill-function/:user-cancel-function/etc would be useful. :on-outcome now has a better default: `org-pending-on-outcome-replace' (see above). The predefined values for :before-kill-function and :user-cancel-function seem OK to me. We will see, when using org-pending, if some patterns need to be included in org-pending. >From the many examples provided in the branch, do you see any that should be included in the library as an other precooked-wrapper, that should be included in the section "Basic use of locks" ? I've added 'org-pending-shell-command-on-region' to my todo list. > > ;; ;; We lock the 'region', defining how to update it when the > ;; ;; outcome is available. > ;; (setq my-lock (org-pending > ;; region > ;; :on-outcome > ;; (lambda (_rl outcome) > ;; (pcase outcome > ;; (`(:success ,value) > ;; ;; On :success, we replace the region with the > ;; ;; value. > ;; (let ((tmp-end (cdr region))) > ;; (goto-char tmp-end) > ;; (insert (format "%s\n" value)) > ;; (setcdr region (point)) > ;; (delete-region (car region) tmp-end))) > ;; ... > > This example has a major problem if user edits the buffer text _before_ > locked region before the outcome is available. > (car region) and (cdr region) will no longer be accurate, and your code > will replace text in places you do not expect. > I believe that it will be better to query region-lock object about the > region location where we need to replace text: > > (setq region (org-pending-reglock-region rl)) > > Same for reglock buffer in other examples. > > Then, we will keep the possibility open for org-pending to handle cases > like killing/yanking text containing reglocks (org-refile) - org-pending > may in future keep track of them. I see. Good point! But note that the region is a "read-only constant" field; archiving/refiling live locks is forbidden. I modified the example to rely on the reglock when possible (as opposed to values kept from the creation time). > > ;; (setf (org-pending-reglock-user-cancel-function my-lock) > ;; (let ((this-timer my-timer)) > ;; (lambda (_rl) > ;; (cancel-timer this-timer) > ;; ... > > ;; (setf (org-pending-reglock-before-kill-function my-lock) > ;; (let ((this-timer my-timer)) > ;; (lambda (_rl) > ;; (message "Killing %s" this-timer) > ;; (cancel-timer this-timer)))) > > 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'. I've made some improvements about the kill behaviour and documentation. I've pushed my changes to my public branch. Bruno