bug#45212: org-capture user-error: Abort

[Ihor Radchenko <yantar92@gmail.com>]

Jean Louis <bugs@gnu.support> writes:

> * 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:

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