From: Jean Louis <bugs@gnu.support>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: daniela-spit@gmx.it, 45212@debbugs.gnu.org
Subject: bug#45212: org-capture user-error: Abort
Date: Sun, 13 Dec 2020 08:46:29 +0300 [thread overview]
Message-ID: <X9WqtQfOQZjpNk7p@protected.rcdrun.com> (raw)
In-Reply-To: <878sa25nja.fsf@localhost>
* Ihor Radchenko <yantar92@gmail.com> [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
next prev parent reply other threads:[~2020-12-13 5:51 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-12 20:15 org-capture user-error: Abort daniela-spit
2020-12-13 1:07 ` Ihor Radchenko
2020-12-13 1:34 ` bug#45212: " daniela-spit
2020-12-13 1:39 ` daniela-spit
2020-12-13 2:51 ` Ihor Radchenko
2020-12-13 3:01 ` daniela-spit
2020-12-13 4:37 ` Ihor Radchenko
2020-12-13 5:16 ` daniela-spit
2020-12-13 5:46 ` Jean Louis [this message]
2020-12-13 8:55 ` Ihor Radchenko
2020-12-13 18:07 ` Diego Zamboni
2020-12-13 18:11 ` daniela-spit
2020-12-13 5:22 ` Jean Louis
2020-12-13 5:54 ` bug#45212: " daniela-spit
2020-12-13 8:24 ` Ihor Radchenko
2020-12-13 10:46 ` Jean Louis
2020-12-13 17:37 ` bug#45212: " Christopher Dimech
2020-12-13 8:25 ` Michael Albinus
2020-12-13 10:48 ` Jean Louis
2020-12-13 17:41 ` bug#45212: " daniela-spit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=X9WqtQfOQZjpNk7p@protected.rcdrun.com \
--to=bugs@gnu.support \
--cc=45212@debbugs.gnu.org \
--cc=daniela-spit@gmx.it \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).