Package: org-mode;
View this message in rfc822 format
From: Ihor Radchenko <yantar92 <at> gmail.com> To: Jean Louis <bugs <at> gnu.support> Cc: daniela-spit <at> gmx.it, 45212 <at> debbugs.gnu.org Subject: bug#45212: org-capture user-error: Abort Date: Sun, 13 Dec 2020 16:55:51 +0800
Jean Louis <bugs <at> gnu.support> writes: > * Ihor Radchenko <yantar92 <at> 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.