From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <83lh17ati6.fsf@gnu.org> <83h9bvarb6.fsf@gnu.org> <83mvllaa4u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468421365 1952 80.91.229.3 (13 Jul 2016 14:49:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2016 14:49:25 +0000 (UTC) Cc: schwab@suse.de, 23949@debbugs.gnu.org, kaushal.modi@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 13 16:49:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bNLTP-0006Uq-3E for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 16:49:15 +0200 Original-Received: from localhost ([::1]:48186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNLTO-0000dk-Bk for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Jul 2016 10:49:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53125) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNLTF-0000c0-W1 for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:49:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNLTC-00085l-LO for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:49:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNLTC-00085g-IG for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bNLTC-0003Wg-Eh for bug-gnu-emacs@gnu.org; Wed, 13 Jul 2016 10:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Jul 2016 14:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23949 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23949-submit@debbugs.gnu.org id=B23949.146842130513509 (code B ref 23949); Wed, 13 Jul 2016 14:49:02 +0000 Original-Received: (at 23949) by debbugs.gnu.org; 13 Jul 2016 14:48:25 +0000 Original-Received: from localhost ([127.0.0.1]:49943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNLSa-0003Vp-SX for submit@debbugs.gnu.org; Wed, 13 Jul 2016 10:48:25 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:57417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bNLSZ-0003Vc-83 for 23949@debbugs.gnu.org; Wed, 13 Jul 2016 10:48:24 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AlIgA731xV/3mcpUVcgxCEAoVVv06DPQQCAoE8PRABAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kLIgLCM8jAQEBBwIBH4s6gT0Bg0cHhC0FnxeGaY0/gUUjgWYxgX0igngBAQE X-IPAS-Result: A0AlIgA731xV/3mcpUVcgxCEAoVVv06DPQQCAoE8PRABAQEBAQEBgQpBBYNdAQEDAVYjBQsLNBIUGA0kLIgLCM8jAQEBBwIBH4s6gT0Bg0cHhC0FnxeGaY0/gUUjgWYxgX0igngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="247764801" Original-Received: from 69-165-156-121.dsl.teksavvy.com (HELO pastel.home) ([69.165.156.121]) by ironport2-out.teksavvy.com with ESMTP; 13 Jul 2016 10:48:29 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 5000564CB1; Wed, 13 Jul 2016 10:48:15 -0400 (EDT) In-Reply-To: <83mvllaa4u.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 13 Jul 2016 17:24:49 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:120997 Archived-At: > 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