unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Eli Zaretskii <eliz@gnu.org>
Cc: schwab@suse.de, 23949@debbugs.gnu.org, kaushal.modi@gmail.com
Subject: bug#23949: 25.0.95; Regression in handling error caused by (string-match-p "." nil)
Date: Wed, 13 Jul 2016 10:48:15 -0400	[thread overview]
Message-ID: <jwvziplvc8f.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <83mvllaa4u.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Jul 2016 17:24:49 +0300")

> Dynamically binding variables around some expression is standard Emacs
> Lisp programming technique, used all over the place.

For sure.  But it's risky and does cause problems in lots of corner
cases (which luckily for us are very rarely triggered).

E.g. we often use re-search-forward or string-match without binding
case-fold-search explicitly, so we depend on the particular setting it
happens to have.  In some cases it truly doesn't matter, while in others
it happens to work because in 99% of the cases the code is run with the
right setting.

Same for completion-ignore-case, completion-regexp-list,
inhibit-read-only, ...

That's just part of life in Elisp.
And I'm not sure what a real "fix" would look like.  E.g. for
minibuffer-setup-hook, we have minibuffer-with-setup-hook but it's
pretty hackish.

Instead, we just live with it and fix the corner cases that we actually
bump into.

> I also think that the "breaks a lot of Elisp code" part is at least a
> tad exaggerated.

Binding inhibit-changing-match-data to t will pretty much break any
function that uses match-beginning or match-end.  I think that counts as
"a lot of Elisp code".  Of course, we currently don't have any code that
binds inhibit-changing-match-data to t around calls to those functions,
except when the calls happen via the debugger.  But it could rear its
ugly head in other cases, e.g. if/when we make it possible for the
regexp-engine to run Elisp code (there can be various reasons to do
that.  Such as to setup the syntax-table property lazily, or to allow
the regexp primitives to be expanded in Elisp [I've a long term desire
to do so for the zero-length primitives such as \< ]) or to pause and
run timers or process filters.

> (defsubst string-match-p (regexp string &optional start)
>   "\
> Same as `string-match' except this function does not change the match data."
>   (condition-case err
>       (let ((inhibit-changing-match-data t))
> 	(string-match regexp string start))
>     (error (signal (car err) (cdr err)))))

That will still cause the same problems when debug-on-signal is non-nil.


        Stefan





  reply	other threads:[~2016-07-13 14:48 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-06  1:56 bug#24166: With --eval, errors in string-match-p do not produce backtraces (but errors in string-match do?!) Clément Pit--Claudel
2016-08-06  2:15 ` npostavs
2016-08-06  3:03   ` Clément Pit--Claudel
2016-08-06  7:25   ` Eli Zaretskii
2016-08-06 10:28     ` Noam Postavsky
2016-08-06 10:34       ` Eli Zaretskii
2016-08-06 10:49         ` Noam Postavsky
2016-08-06 11:19           ` Eli Zaretskii
2016-08-06 12:25             ` npostavs
2016-08-07 14:12               ` Eli Zaretskii
2016-08-07 14:27                 ` npostavs
2016-07-11 20:12                   ` bug#23949: 25.0.95; Regression in handling error caused by (string-match-p "." nil) Kaushal Modi
2016-07-12 12:29                     ` Kaushal Modi
2016-07-12 13:14                       ` Eli Zaretskii
2016-07-12 13:33                         ` Kaushal Modi
2016-07-12 13:37                           ` Kaushal Modi
2016-07-12 14:03                             ` Eli Zaretskii
2016-07-12 14:01                           ` Eli Zaretskii
2016-07-12 18:35                             ` Kaushal Modi
2016-07-12 18:55                               ` Noam Postavsky
2016-07-12 19:00                                 ` Kaushal Modi
2016-07-12 19:12                                   ` Eli Zaretskii
2016-07-12 19:10                               ` Eli Zaretskii
2016-07-12 19:19                               ` Eli Zaretskii
2016-07-12 19:29                                 ` Kaushal Modi
2016-07-12 20:27                               ` Stefan Monnier
2016-07-13 13:10                                 ` Kaushal Modi
2016-07-13 13:59                                   ` Stefan Monnier
2016-07-13 15:06                                     ` Eli Zaretskii
2016-07-13 15:03                                   ` Eli Zaretskii
2016-07-13 14:24                                 ` Eli Zaretskii
2016-07-13 14:48                                   ` Stefan Monnier [this message]
2016-07-13 15:14                                     ` Eli Zaretskii
2016-07-13 16:00                                       ` Stefan Monnier
2016-07-13 16:18                                         ` Eli Zaretskii
2016-07-13 16:41                                           ` Stefan Monnier
2016-07-13 15:03                                   ` Andreas Schwab
2016-07-13 15:17                                     ` Eli Zaretskii
2016-07-12 14:15                           ` Andreas Schwab
     [not found]                     ` <handler.23949.C.147058007223290.notifdonectrl.2@debbugs.gnu.org>
2016-08-09 15:56                       ` bug#23949: acknowledged by developer (Re: bug#24166: With --eval, errors in string-match-p do not produce backtraces (but errors in string-match do?!)) Kaushal Modi
2016-08-07 15:43                   ` bug#24166: With --eval, errors in string-match-p do not produce backtraces (but errors in string-match do?!) Clément Pit--Claudel

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=jwvziplvc8f.fsf-monnier+emacsbugs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=23949@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=kaushal.modi@gmail.com \
    --cc=schwab@suse.de \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).