all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@gmail.com>
To: daniela-spit@gmx.it
Cc: 45212@debbugs.gnu.org
Subject: bug#45212: org-capture user-error: Abort
Date: Sun, 13 Dec 2020 12:37:45 +0800	[thread overview]
Message-ID: <878sa25nja.fsf@localhost> (raw)
In-Reply-To: <trinity-de792c09-d7dd-43a4-9941-67bb68a5e950-1607828508267@3c-app-mailcom-bs06>

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





  reply	other threads:[~2020-12-13  4:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12 20:15 org-capture user-error: Abort daniela-spit
2020-12-13  1:07 ` Ihor Radchenko
2020-12-13  1:34   ` bug#45212: " daniela-spit
2020-12-13  1:39     ` daniela-spit
2020-12-13  2:51       ` Ihor Radchenko
2020-12-13  3:01         ` daniela-spit
2020-12-13  4:37           ` Ihor Radchenko [this message]
2020-12-13  5:16             ` daniela-spit
2020-12-13  5:46             ` Jean Louis
2020-12-13  8:55               ` Ihor Radchenko
2020-12-13 18:07   ` Diego Zamboni
2020-12-13 18:11     ` daniela-spit
2020-12-13 18:11       ` daniela-spit
2020-12-13  5:22 ` Jean Louis
2020-12-13  5:54   ` bug#45212: " daniela-spit
2020-12-13  8:24   ` Ihor Radchenko
2020-12-13 10:46     ` Jean Louis
2020-12-13 17:37       ` bug#45212: " Christopher Dimech
2020-12-13  8:25   ` Michael Albinus
2020-12-13 10:48     ` Jean Louis
2020-12-13 17:41       ` bug#45212: " daniela-spit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878sa25nja.fsf@localhost \
    --to=yantar92@gmail.com \
    --cc=45212@debbugs.gnu.org \
    --cc=daniela-spit@gmx.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.