emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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




  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).