Jean Louis <bugs@gnu.support> writes: > * Ihor Radchenko <yanta...@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