org-capture user-error: Abort

org-capture user-error: Abort

[daniela-spit]

Emacs fires "user-error: Abort" after pressing "q" to abort org-capture.

Re: org-capture user-error: Abort

[Ihor Radchenko]

daniela-spit@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

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

[daniela-spit]

> Sent: Sunday, December 13, 2020 at 2:07 AM
> From: "Ihor Radchenko" <yantar92@gmail.com>
> To: daniela-spit@gmx.it, 45212@debbugs.gnu.org
> Subject: bug#45212: org-capture user-error: Abort
>
> daniela-spit@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
>
>
>
>
>

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

[daniela-spit]

> Sent: Sunday, December 13, 2020 at 2:34 AM
> From: daniela-spit@gmx.it
> To: "Ihor Radchenko" <yantar92@gmail.com>
> Cc: 45212@debbugs.gnu.org
> Subject: bug#45212: org-capture user-error: Abort
>
>
>
> > Sent: Sunday, December 13, 2020 at 2:07 AM
> > From: "Ihor Radchenko" <yantar92@gmail.com>
> > To: daniela-spit@gmx.it, 45212@debbugs.gnu.org
> > Subject: bug#45212: org-capture user-error: Abort
> >
> > daniela-spit@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

[Ihor Radchenko]

daniela-spit@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

[daniela-spit]

> Sent: Sunday, December 13, 2020 at 3:51 AM
> From: "Ihor Radchenko" <yantar92@gmail.com>
> To: daniela-spit@gmx.it, daniela-spit@gmx.it
> Cc: 45212@debbugs.gnu.org
> Subject: bug#45212: org-capture user-error: Abort
>
> daniela-spit@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

[Ihor Radchenko]

daniela-spit@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
 <run capture>
(t <work around the "Abort" error>))

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

[daniela-spit]

> Sent: Sunday, December 13, 2020 at 5:37 AM
> From: "Ihor Radchenko" <yantar92@gmail.com>
> To: daniela-spit@gmx.it
> Cc: 45212@debbugs.gnu.org
> Subject: bug#45212: org-capture user-error: Abort
>
> daniela-spit@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
>  <run capture>
> (t <work around the "Abort" error>))
>
> 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

[Jean Louis]

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

- 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

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

[Ihor Radchenko]

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

Re: org-capture user-error: Abort

[Diego Zamboni]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

>
>
> > 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?

[-- Attachment #2: Type: text/html, Size: 775 bytes --]

Re: org-capture user-error: Abort

[daniela-spit]

[-- Attachment #1: Type: text/html, Size: 1860 bytes --]

Re: org-capture user-error: Abort

[daniela-spit]

[-- Attachment #1: Type: text/html, Size: 1859 bytes --]

Re: org-capture user-error: Abort

[Jean Louis]

* daniela-spit@gmx.it <daniela-spit@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

[daniela-spit]

> Sent: Sunday, December 13, 2020 at 6:22 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: daniela-spit@gmx.it
> Cc: 45212@debbugs.gnu.org
> Subject: bug#45212: org-capture user-error: Abort
>
> * daniela-spit@gmx.it <daniela-spit@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

>
>

Re: org-capture user-error: Abort

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> * daniela-spit@gmx.it <daniela-spit@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".  

Re: org-capture user-error: Abort

[Jean Louis]

* Ihor Radchenko <yantar92@gmail.com> [2020-12-13 11:21]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * daniela-spit@gmx.it <daniela-spit@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

[Christopher Dimech]

> Sent: Sunday, December 13, 2020 at 11:46 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Ihor Radchenko" <yantar92@gmail.com>
> Cc: daniela-spit@gmx.it, bug-gnu-emacs@gnu.org, "Org-Mode mailing list" <emacs-orgmode@gnu.org>
> Subject: Re: org-capture user-error: Abort
>
> * Ihor Radchenko <yantar92@gmail.com> [2020-12-13 11:21]:
> > Jean Louis <bugs@gnu.support> writes:
> > 
> > > * daniela-spit@gmx.it <daniela-spit@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]

Jean Louis <bugs@gnu.support> 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]

* Michael Albinus <michael.albinus@gmx.de> [2020-12-13 11:25]:
> Jean Louis <bugs@gnu.support> 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

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

[daniela-spit]

> Sent: Sunday, December 13, 2020 at 11:48 AM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Michael Albinus" <michael.albinus@gmx.de>
> Cc: daniela-spit@gmx.it, bug-gnu-emacs@gnu.org, "Org-Mode mailing list" <emacs-orgmode@gnu.org>
> Subject: Re: org-capture user-error: Abort
>
> * Michael Albinus <michael.albinus@gmx.de> [2020-12-13 11:25]:
> > Jean Louis <bugs@gnu.support> 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
>
>