From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AHZzL+Gr1V9UVAAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 05:51:29 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id QGoqK+Gr1V/JbAAAbx9fmQ (envelope-from ) for ; Sun, 13 Dec 2020 05:51:29 +0000 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 3E4499403EB for ; Sun, 13 Dec 2020 05:51:29 +0000 (UTC) Received: from localhost ([::1]:57108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koKI3-0007HF-Oi for larch@yhetil.org; Sun, 13 Dec 2020 00:51:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koKHe-0007FZ-MB for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 00:51:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:35749) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koKHe-0000wE-Dm for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 00:51:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1koKHe-0004JQ-AR for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 00:51:02 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#45212: org-capture user-error: Abort Resent-From: Jean Louis Original-Sender: "Debbugs-submit" Resent-CC: emacs-orgmode@gnu.org Resent-Date: Sun, 13 Dec 2020 05:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45212 X-GNU-PR-Package: org-mode X-GNU-PR-Keywords: To: Ihor Radchenko Received: via spool by 45212-submit@debbugs.gnu.org id=B45212.160783860416456 (code B ref 45212); Sun, 13 Dec 2020 05:51:02 +0000 Received: (at 45212) by debbugs.gnu.org; 13 Dec 2020 05:50:04 +0000 Received: from localhost ([127.0.0.1]:47295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koKGh-0004HK-Fl for submit@debbugs.gnu.org; Sun, 13 Dec 2020 00:50:04 -0500 Received: from stw1.rcdrun.com ([217.170.207.13]:57463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koKGf-0004Gh-9p for 45212@debbugs.gnu.org; Sun, 13 Dec 2020 00:50:02 -0500 Received: from localhost ([::ffff:41.202.241.30]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000442C8.000000005FD5AB81.0000149B; Sat, 12 Dec 2020 22:49:53 -0700 Date: Sun, 13 Dec 2020 08:46:29 +0300 From: Jean Louis Message-ID: References: <87sg8a5x98.fsf@localhost> <87bley5sfo.fsf@localhost> <878sa25nja.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <878sa25nja.fsf@localhost> User-Agent: Mutt/2.0 (3d08634) (2020-11-07) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: emacs-orgmode@gnu.org List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: daniela-spit@gmx.it, 45212@debbugs.gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.80 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 3E4499403EB X-Spam-Score: -1.80 X-Migadu-Scanner: scn1.migadu.com X-TUID: wNLb3rlsKL33 * Ihor Radchenko [2020-12-13 07:35]: > > What case scenarios would rely > > on user quitting capture rather than going ahead with an entry? > > For example, I have a custom capture function from email. The email is > removed from inbox upon capture. However, I would not want to proceed > with removal if capture is aborted for whatever reason. If user wish to capture maybe it should be done more atomic and safely for some types of capturing email message ID, or emails, or capturing URLs, basically that data which already exists and which user need not create oneself. It excludes notes for example or anything related to real time annotations: - item that user wants to be captured should be captured in separate storage which I will mark here as (S) at the moment that users desired to do so. Nothing else should prevent that capture. Implementation of the storage is not important. Maybe it could be one file among many in a directory, maybe it could be in one big file, it does not matter. - in the next step would come the formatting of the storage. This can be aborted as people do various things. Maybe they wish to put some date, or this or that. When user signals that capture editing is finished at that moment only would the item from the storage (S) be removed. Examples of such workflow: - URL that only need to be captured without much annotations, click button. Finished. When time comes sort one by one into various categories. Not in real time. In real time user is browsing Internet and may like rather to continue reading the WWW instead of annotating the URLs or sorting into some categories. Click once, and Emacs WILL NOT open. It captured the URL. Why it should open? Annotate it or categorize it later when you annotate many items at once. - Messages like you said, one click. Finished. If necessary categorize later several messages at once. As a side note messages are always related to people or groups of people such as Org users. I am always extracting the email address and relating message to people automatically. - Pictures, videos, files quickly captured when browsing or searching for files. - Tasks related to message by related people I was always capturing with one single F10 or F11 in mutt. No thinking more than this. The subject and person would get captured. Later I have the list of the simple TODOs, how I called it and how I will soon re-implement it. Such tasks are more a reference to my thought. My thought is not written anywhere and for onlooker it would be not conclusive why I have captured that as an action. It is just a reference: person's name, subject, maybe email body, all that is reference as it associates me to the thought of some action I have to do related to that. But I need not write that action anywhere. That way a series of actions and series of thoughts do not get interrupted by Emacs capture window opening and requesting user to write something. Instead the item is capture by one key and user continues with the original uninterrputed serious of actions and thoughts. Focus remains on one action getting done, while some actions are postponed for later review. Later review is again done in a series of actions and thoughts not interrupted by something else. For collaboration this will not work. In that case one has to annotate things as the captured item does not serve well as association to the thought. The thought has to be written for collaboration unless group has well aligned thoughts to understand the meaning from the reference provided. Jean