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 VG5SAorW1V9+DQAA0tVLHw (envelope-from ) for ; Sun, 13 Dec 2020 08:53:30 +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 cP1OOYnW1V/EDwAAbx9fmQ (envelope-from ) for ; Sun, 13 Dec 2020 08:53: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 4AA979402A2 for ; Sun, 13 Dec 2020 08:53:29 +0000 (UTC) Received: from localhost ([::1]:45854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1koN8B-0007xf-UW for larch@yhetil.org; Sun, 13 Dec 2020 03:53:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koN7l-0007w1-UM for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 03:53:01 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:35857) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koN7l-0002Lf-M7 for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 03:53:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1koN7l-0002mb-Kk for emacs-orgmode@gnu.org; Sun, 13 Dec 2020 03:53:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#45212: org-capture user-error: Abort Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: emacs-orgmode@gnu.org Resent-Date: Sun, 13 Dec 2020 08:53:01 +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: Jean Louis Received: via spool by 45212-submit@debbugs.gnu.org id=B45212.160784953410594 (code B ref 45212); Sun, 13 Dec 2020 08:53:01 +0000 Received: (at 45212) by debbugs.gnu.org; 13 Dec 2020 08:52:14 +0000 Received: from localhost ([127.0.0.1]:47403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koN6z-0002kn-RC for submit@debbugs.gnu.org; Sun, 13 Dec 2020 03:52:14 -0500 Received: from mail-pf1-f182.google.com ([209.85.210.182]:37474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koN6x-0002kQ-LV for 45212@debbugs.gnu.org; Sun, 13 Dec 2020 03:52:12 -0500 Received: by mail-pf1-f182.google.com with SMTP id 11so10068135pfu.4 for <45212@debbugs.gnu.org>; Sun, 13 Dec 2020 00:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=KGi+rnvUX1ASfOTucLkHBbCtD4bpr+qCZRIOKWEWwBI=; b=k0qAU0ZRbWgS+88EJ6h1QAtwpRWVzpiArFzqdMS73LHaVysFlqR+I6be8kyiBgboEH jg+4MrSp0zkXE7eT7QYwpwagWAZOBkE7L8IW6bGJNqvQ+OpxRL6LpxDIk9BZV692W8wg XkxOsSdhNTHQvtYj3+qBd6dy6UQ5eZe7dRE99Uccl7s2qA6xtfji9dQ/UQk0ncNB+sAc MYtXGBQ33asntFahmk+IcvMuTNfYc7mgvdpYNlaov0GT8ZQt0hK1TrXCoHiS/cyUPKif mCLQTfWi08OVbE6OWpmQzwGCaPW5hMMBPP/jWf0DjkpfVAkOAQr1GKj2xOAFlBPlJtqC 3i+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=KGi+rnvUX1ASfOTucLkHBbCtD4bpr+qCZRIOKWEWwBI=; b=nw+UU5KdqFRhRak3bmjZYpvnaee9vtilGLZRnhJQy2bC3V3roVwVwJOonFDTBNAFqG zYdDtixWPqe66u3z44uEQS8eaXfo1lkjghJeUZ5mP6IkSmPbmSAKYtaflVVhfydw2O26 GhVY4hRknQIctMG/X0v4DvOwgghlXm5osIvWHAHp9P91KUDAG6+A7wEdFuwksTUdatlU oT1sWN5JqAP1SUldeSEWC7inTdSbb2GzNo44VMbkeAtmVYqjSIG6SAUkKcvdL+2R8vIF LFiyGFwdneBOVII+GpYYd2lcRBTxzJltaQS7O4iqlANE44905bRhmqYXZ8ShffU5n6tF N8eg== X-Gm-Message-State: AOAM530iWymXgE2XbRGL+reMlZ5WnIZrk2lyZqU/fZ4InhJOPYp9K649 s7Pj+cyS/AiKwc1n0cFgcgE= X-Google-Smtp-Source: ABdhPJw/fZpMQnBq5H6U4MH+I0wYpKjBRbZo+GDTKJKkr75qQ5ivacGxk62snVPOFtQPbD+AI87DLA== X-Received: by 2002:a63:1a13:: with SMTP id a19mr19111947pga.146.1607849525356; Sun, 13 Dec 2020 00:52:05 -0800 (PST) Received: from localhost ([50.7.251.66]) by smtp.gmail.com with ESMTPSA id x12sm16282623pfj.25.2020.12.13.00.52.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Dec 2020 00:52:04 -0800 (PST) From: Ihor Radchenko In-Reply-To: References: <87sg8a5x98.fsf@localhost> <87bley5sfo.fsf@localhost> <878sa25nja.fsf@localhost> Date: Sun, 13 Dec 2020 16:55:51 +0800 Message-ID: <871rfu5bl4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain 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: -0.70 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=k0qAU0ZR; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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: 4AA979402A2 X-Spam-Score: -0.70 X-Migadu-Scanner: scn1.migadu.com X-TUID: 8VvS6f+J1vNw Jean Louis writes: > * 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: It is pretty much what I do. For safety, (condition-case ...) is taking care of capturing whatever unexpected error happens. With current org-capture behaviour, condition-case also happens to cover aborting capture. Further, "removing from inbox" for my case merely means removing "inbox" tag from the email. I think I never deleted a single email from my local mailbox for the last 5 years or so. > - 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. It is how org-capture works internally ;) Capture is put into real org file (not a temporary file). It is only removed if used explicitly aborts the process. > 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. That's why there is :immediate-finish option in org-capture-templates. I use it most of the time I capture web-links (see https://github.com/yantar92/org-capture-ref#capture-setup). > - Messages like you said, one click. Finished. If necessary categorize > later several messages at once. That's what I do with RSS feeds and unimportant emails. > ... 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. It would indeed be useful. In future, I plan to implement auto-linking to my org-contacts upon capture. > - 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. Good if it works for you. I usually need to leave a few "breadcrumb" words during capture to remind myself what I was thinking about. I generally tend not to link my thoughts to specific dates or people. In the past, I tried approach like what you described and ended up forgetting about what I was thinking while capturing something. > 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. I am really surprised that you don't forget the ideas using this workflow. It reminds me that all people are different. Best, Ihor