[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45212: org-capture user-error: Abort
From: |
Ihor Radchenko |
Subject: |
bug#45212: org-capture user-error: Abort |
Date: |
Sun, 13 Dec 2020 16:55:51 +0800 |
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
- 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, 2020/12/13
- bug#45212: org-capture user-error: Abort,
Ihor Radchenko <=
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