[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45212: org-capture user-error: Abort
From: |
Jean Louis |
Subject: |
bug#45212: org-capture user-error: Abort |
Date: |
Sun, 13 Dec 2020 08:46:29 +0300 |
User-agent: |
Mutt/2.0 (3d08634) (2020-11-07) |
* 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
- org-capture user-error: Abort, daniela-spit, 2020/12/12
- Re: org-capture user-error: Abort, Ihor Radchenko, 2020/12/12
- bug#45212: org-capture user-error: Abort, daniela-spit, 2020/12/12
- bug#45212: org-capture user-error: Abort, daniela-spit, 2020/12/12
- bug#45212: org-capture user-error: Abort, Ihor Radchenko, 2020/12/12
- bug#45212: org-capture user-error: Abort, daniela-spit, 2020/12/12
- bug#45212: org-capture user-error: Abort, Ihor Radchenko, 2020/12/12
- bug#45212: org-capture user-error: Abort, daniela-spit, 2020/12/13
- bug#45212: org-capture user-error: Abort,
Jean Louis <=
- bug#45212: org-capture user-error: Abort, Ihor Radchenko, 2020/12/13
Re: org-capture user-error: Abort, Diego Zamboni, 2020/12/13
Re: org-capture user-error: Abort, Jean Louis, 2020/12/13
Re: org-capture user-error: Abort, Michael Albinus, 2020/12/13