Re: org-capture user-error: Abort
Sent: Sunday, December 13, 2020 at 7:07 PM From: "Diego Zamboni" To: "Ihor Radchenko" Cc: daniela-s...@gmx.it, bug-gnu-em...@gnu.org, "Org-Mode mailing list" Subject: Re: org-capture user-error: Abort > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. This is intended. Normally, it just shows up as a message in the minibuffer. Or do you have debug-on-error enabled? Same as Ihor, when I press `q` in the org-capture screen I only see "Abort" in the minibuffer. Where do you see the `user-error`? As long as the effect is what you need (getting out of the capture screen), what is the problem with the code using the `user-error` function to achieve this effect? I use it to build my templates (incl. switching between templates) and could get many errors. To test functionality, I custamarily abort the capture.
Re: org-capture user-error: Abort
> > > > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > This is intended. Normally, it just shows up as a message in the > minibuffer. Or do you have debug-on-error enabled? > Same as Ihor, when I press `q` in the org-capture screen I only see "Abort" in the minibuffer. Where do you see the `user-error`? As long as the effect is what you need (getting out of the capture screen), what is the problem with the code using the `user-error` function to achieve this effect?
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 11:48 AM > From: "Jean Louis" > To: "Michael Albinus" > Cc: daniela-s...@gmx.it, bug-gnu-em...@gnu.org, "Org-Mode mailing list" > > Subject: Re: org-capture user-error: Abort > > * Michael Albinus [2020-12-13 11:25]: > > Jean Louis writes: > > > > Hi Jean, > > > > > Even if it is error, why it should be written with the dash as > > > "user-error"?! > > > > `user-error' is a standard error symbol in Emacs, which is fired by the > > function `user-error'. See (info "(elisp) Signaling Errors") > > And error is by definition a wrong action attributable to bad judgment > or ignorance or inattention. > > When user is offered choice: > > [q] Abort > > then such is not a wrong action or bad judgment or ignorance or > inattention. Even the function description says it should be used in > different set of circumstances. > > Org capture screen does not provide that circumstance that function > should be used there as user's choice is not an error. When I abort, it is completely intentional. I use frequently for testing new org-capture templates. > Jean > >
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 11:46 AM > From: "Jean Louis" > To: "Ihor Radchenko" > Cc: daniela-s...@gmx.it, bug-gnu-em...@gnu.org, "Org-Mode mailing list" > > Subject: Re: org-capture user-error: Abort > > * Ihor Radchenko [2020-12-13 11:21]: > > Jean Louis writes: > > > > > * daniela-s...@gmx.it [2020-12-12 23:19]: > > >> Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > > > > > Those are error messages invented by programmers who never had any > > > project supervisor who thinks of users. > > > > (user-error "Action aborted") only prints "Action aborted". > > Function is used wrongly. People do read source code. > > (user-error FORMAT &rest ARGS) > > Probably introduced at or before Emacs version 24. > > Signal a user error, making a message by passing ARGS to ‘format-message’. > This is like ‘error’ except that a user error (or "pilot error") comes > from an incorrect manipulation by the user, not from an actual problem. > In contrast with other errors, user errors normally do not cause > entry to the debugger, even when ‘debug-on-error’ is non-nil. > This can be overridden by ‘debug-ignored-errors’. > > Did user incorrectly manipulated anything? I don't think so. > > There was definitely good intention to glue the things together and > make things function. But it was not made from viewpoint that software > will be used by people, maybe people read source code which is what we > want. Under certain condition that will come up as actual error, see > debug-ignored-errors. > > Why tell to user that it was user error when it was not? It was one of > options. I agree absolutely. > Focus on technicality that causes the problem which does not fit > reasonably into human meanings. We like meanings, that is why we want > to fit meanings where they belong. Systems are not enough meaningful. > > I can love my bicycle as I want, but it may not be usable by other > people due to all idiosyncratic enhancements I have made to it. > > Jean > > - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy
Re: org-capture user-error: Abort
* Michael Albinus [2020-12-13 11:25]: > Jean Louis writes: > > Hi Jean, > > > Even if it is error, why it should be written with the dash as > > "user-error"?! > > `user-error' is a standard error symbol in Emacs, which is fired by the > function `user-error'. See (info "(elisp) Signaling Errors") And error is by definition a wrong action attributable to bad judgment or ignorance or inattention. When user is offered choice: [q] Abort then such is not a wrong action or bad judgment or ignorance or inattention. Even the function description says it should be used in different set of circumstances. Org capture screen does not provide that circumstance that function should be used there as user's choice is not an error. Jean
Re: org-capture user-error: Abort
* Ihor Radchenko [2020-12-13 11:21]: > Jean Louis writes: > > > * daniela-s...@gmx.it [2020-12-12 23:19]: > >> Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > > > Those are error messages invented by programmers who never had any > > project supervisor who thinks of users. > > (user-error "Action aborted") only prints "Action aborted". Function is used wrongly. People do read source code. (user-error FORMAT &rest ARGS) Probably introduced at or before Emacs version 24. Signal a user error, making a message by passing ARGS to ‘format-message’. This is like ‘error’ except that a user error (or "pilot error") comes from an incorrect manipulation by the user, not from an actual problem. In contrast with other errors, user errors normally do not cause entry to the debugger, even when ‘debug-on-error’ is non-nil. This can be overridden by ‘debug-ignored-errors’. Did user incorrectly manipulated anything? I don't think so. There was definitely good intention to glue the things together and make things function. But it was not made from viewpoint that software will be used by people, maybe people read source code which is what we want. Under certain condition that will come up as actual error, see debug-ignored-errors. Why tell to user that it was user error when it was not? It was one of options. Focus on technicality that causes the problem which does not fit reasonably into human meanings. We like meanings, that is why we want to fit meanings where they belong. Systems are not enough meaningful. I can love my bicycle as I want, but it may not be usable by other people due to all idiosyncratic enhancements I have made to it. Jean
bug#45212: org-capture user-error: Abort
Jean Louis writes: > * Ihor Radchenko [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
Re: org-capture user-error: Abort
Jean Louis writes: Hi Jean, > Even if it is error, why it should be written with the dash as > "user-error"?! `user-error' is a standard error symbol in Emacs, which is fired by the function `user-error'. See (info "(elisp) Signaling Errors") Best regards, Michael.
Re: org-capture user-error: Abort
Jean Louis writes: > * daniela-s...@gmx.it [2020-12-12 23:19]: >> Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > Those are error messages invented by programmers who never had any > project supervisor who thinks of users. Please be nice. > If user wish to abort it is not an error. Even if it is error, why it > should be written with the dash as "user-error"?! > > If message is at all necessary then computer should say "Action > aborted" or similar. (user-error "Action aborted") only prints "Action aborted".
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 6:22 AM > From: "Jean Louis" > To: daniela-s...@gmx.it > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > * daniela-s...@gmx.it [2020-12-12 23:19]: > > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > Those are error messages invented by programmers who never had any > project supervisor who thinks of users. > > If user wish to abort it is not an error. Even if it is error, why it > should be written with the dash as "user-error"?! > > If message is at all necessary then computer should say "Action > aborted" or similar. Agreed > >
bug#45212: org-capture user-error: Abort
* Ihor Radchenko [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
Re: org-capture user-error: Abort
* daniela-s...@gmx.it [2020-12-12 23:19]: > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. Those are error messages invented by programmers who never had any project supervisor who thinks of users. If user wish to abort it is not an error. Even if it is error, why it should be written with the dash as "user-error"?! If message is at all necessary then computer should say "Action aborted" or similar.
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 5:37 AM > From: "Ihor Radchenko" > To: daniela-s...@gmx.it > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > daniela-s...@gmx.it writes: > > > Can't one throw a capture abort signal instead? > > Sure, that is possible. However, consider a possibility that some > external package wants to detect when capture is aborted. If I was > writing such package, I would need to do something like > > (condition-case err > > (t )) > > If org-capture is rewritten using catch-throw, the above code would be > broken. Also, there will be no easy way for a user to know if the > capture was completed successfully or if it was aborted. The problem is not the "Abort" itself, but more precisely "user-error", rather than Abort. I suppose that depends on how many packages on ELPA check on "capture user-error". > Note that I do not oppose this change too firmly. I agree that throw (or > even just normal exit) would be cleaner. However, changing user-error to > throw may break external packages and should be considered carefully. On > the other hand, user-error is internal detail of the implementation. So, > changing it should not be a big deal. As a precaution, it can be > announced and implemented as a part of major release. > > If you want this change to happen, I suggest to provide the patch. This > will encourage the maintainers to provide feedback. It is not so much about imposing it, but it would make the whole thing cleaner as you described. > > 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. I see. Still, I am not against signaling an abort. > Best, > Ihor > > > > >
bug#45212: org-capture user-error: Abort
daniela-s...@gmx.it writes: > Can't one throw a capture abort signal instead? Sure, that is possible. However, consider a possibility that some external package wants to detect when capture is aborted. If I was writing such package, I would need to do something like (condition-case err (t )) If org-capture is rewritten using catch-throw, the above code would be broken. Also, there will be no easy way for a user to know if the capture was completed successfully or if it was aborted. Note that I do not oppose this change too firmly. I agree that throw (or even just normal exit) would be cleaner. However, changing user-error to throw may break external packages and should be considered carefully. On the other hand, user-error is internal detail of the implementation. So, changing it should not be a big deal. As a precaution, it can be announced and implemented as a part of major release. If you want this change to happen, I suggest to provide the patch. This will encourage the maintainers to provide feedback. > 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. Best, Ihor
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 3:51 AM > From: "Ihor Radchenko" > To: daniela-s...@gmx.it, daniela-s...@gmx.it > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > daniela-s...@gmx.it writes: > > > Why it is intended? The user wanted to abort and Emacs obeyed. (q) is an > > option, the user used it, > > and Emacs should not throw an error at the user. > > I guess the intention was throwing signal + showing message to user. The > same could certainly be implemented without user-error. However, some > packages might be relying on the present behaviour and changing it could > break user's workflows. If you have any ideas how to implement quitting > from org-capture without using user-error *and supporting backward > compatibility*, patches are welcome. Can't one throw a capture abort signal instead? What case scenarios would rely on user quitting capture rather than going ahead with an entry? > Also, you can add this error to debug-ignored-errors to avoid annoyance > when debug-on-error is active. > > Best, > Ihor > > > > > >
bug#45212: org-capture user-error: Abort
daniela-s...@gmx.it writes: > Why it is intended? The user wanted to abort and Emacs obeyed. (q) is an > option, the user used it, > and Emacs should not throw an error at the user. I guess the intention was throwing signal + showing message to user. The same could certainly be implemented without user-error. However, some packages might be relying on the present behaviour and changing it could break user's workflows. If you have any ideas how to implement quitting from org-capture without using user-error *and supporting backward compatibility*, patches are welcome. Also, you can add this error to debug-ignored-errors to avoid annoyance when debug-on-error is active. Best, Ihor
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 2:34 AM > From: daniela-s...@gmx.it > To: "Ihor Radchenko" > Cc: 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > > > > Sent: Sunday, December 13, 2020 at 2:07 AM > > From: "Ihor Radchenko" > > To: daniela-s...@gmx.it, 45...@debbugs.gnu.org > > Subject: bug#45212: org-capture user-error: Abort > > > > daniela-s...@gmx.it writes: > > > > > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > > > This is intended. Normally, it just shows up as a message in the > > minibuffer. Or do you have debug-on-error enabled? > > I have debug-on-error enabled Why it is intended? The user wanted to abort and Emacs obeyed. (q) is an option, the user used it, and Emacs should not throw an error at the user. > > Best, > > Ihor > > > > > > > > > > > > > >
bug#45212: org-capture user-error: Abort
> Sent: Sunday, December 13, 2020 at 2:07 AM > From: "Ihor Radchenko" > To: daniela-s...@gmx.it, 45...@debbugs.gnu.org > Subject: bug#45212: org-capture user-error: Abort > > daniela-s...@gmx.it writes: > > > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. > > This is intended. Normally, it just shows up as a message in the > minibuffer. Or do you have debug-on-error enabled? I have debug-on-error enabled > Best, > Ihor > > > > >
Re: org-capture user-error: Abort
daniela-s...@gmx.it writes: > Emacs fires "user-error: Abort" after pressing "q" to abort org-capture. This is intended. Normally, it just shows up as a message in the minibuffer. Or do you have debug-on-error enabled? Best, Ihor
org-capture user-error: Abort
Emacs fires "user-error: Abort" after pressing "q" to abort org-capture.
