From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 14724@debbugs.gnu.org
Subject: bug#14724: 24.3.50; `isearch-open-necessary-overlays' handling of overlay property 'isearch-open-invisible'
Date: Wed, 26 Jun 2013 19:38:19 -0700 (PDT) [thread overview]
Message-ID: <5579ad7c-967c-4635-b9cc-758968faddb1@default> (raw)
In-Reply-To: <jwvehbo8hj0.fsf-monnier+emacs@gnu.org>
> > The code would be more robust if it would gracefully handle (1) an
> > non-functional value and perhaps
>
> Wouldn't such a non-function non-nil value reflect an error in an
> Elisp package?
Yes, normally. In Elisp code, whether a package or not, and whether distributed by Emacs Dev or not.
> If so, why should we silence it?
It would allow 3rd-party code that might not be correct in this regard to at least allow Isearch to continue to function normally otherwise.
The only reasonable value is a function, since we immediately invoke funcall with it. I'm guessing it might not be obvious to someone where the error lies.
It costs nothing for the code to protect itself from funcalling a non-function here and thus fail gracefully with a no-op. Someone trying to use this feature will as likely dig in to figure out the problem with a non-action as with an error, but users would at least not be impacted.
Of course I agree that raising an error for incorrect code is typically TRT. I'm not sure it is in this case. See what I said about `isearch-open-invisible-temporary', which is different in that it is not set up in distant code but is internal to isearch.el.
> > For (1+2), that could be wrapped in `ignore-errors'.
>
> I thing I disagree with ignore-errors here (at least, I don't think such
> errors are normal, so they shouldn't be silenced), but using
> with-demoted-errors could make sense if errors in this code could make
> isearch non-functional. Is that the case?
An error is raised; that's all - Isearch is not broken by it. Yes, `with-demoted-errors' makes more sense. The same considerations apply here as for a non-function: better a no-op (a msg is OK) than an error, I think.
Whatever you decide is fine with me. I'm essentially bringing it to your attention. Perhaps Juri has some input on this?
next prev parent reply other threads:[~2013-06-27 2:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-26 16:24 bug#14724: 24.3.50; `isearch-open-necessary-overlays' handling of overlay property 'isearch-open-invisible' Drew Adams
2013-06-27 1:37 ` Stefan Monnier
2013-06-27 2:38 ` Drew Adams [this message]
2013-06-27 3:00 ` Stefan Monnier
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=5579ad7c-967c-4635-b9cc-758968faddb1@default \
--to=drew.adams@oracle.com \
--cc=14724@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.