From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#24914: 24.5; isearch-regexp: wrong error message Date: Mon, 4 Dec 2017 06:52:27 -0800 (PST) Message-ID: References: <7c208ac0-8aa2-4db8-a38d-760f91c50500@default> <87h8t7ix7m.fsf@users.sourceforge.net> <87d13visrh.fsf@users.sourceforge.net> <87shcrgg8g.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1512399191 30480 195.159.176.226 (4 Dec 2017 14:53:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 14:53:11 +0000 (UTC) Cc: 24914@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 04 15:53:08 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLs7H-0007fP-C7 for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Dec 2017 15:53:07 +0100 Original-Received: from localhost ([::1]:43552 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLs7O-0002eE-Mb for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Dec 2017 09:53:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLs7H-0002bO-AC for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 09:53:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLs7D-0007SG-2t for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 09:53:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35814) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLs7C-0007S7-Ul for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 09:53:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eLs7C-0000Rf-I0 for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 09:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Dec 2017 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24914 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 24914-submit@debbugs.gnu.org id=B24914.15123991581672 (code B ref 24914); Mon, 04 Dec 2017 14:53:02 +0000 Original-Received: (at 24914) by debbugs.gnu.org; 4 Dec 2017 14:52:38 +0000 Original-Received: from localhost ([127.0.0.1]:44495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLs6o-0000Qt-Cu for submit@debbugs.gnu.org; Mon, 04 Dec 2017 09:52:38 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:52791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLs6m-0000Qg-O7 for 24914@debbugs.gnu.org; Mon, 04 Dec 2017 09:52:37 -0500 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vB4EqGXP132946; Mon, 4 Dec 2017 14:52:30 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=qD1a4M+OkCVPrmSJgXiCfxkdXAYMbXJpOkKjvcOyBQ8=; b=Z/QY+TOUQZTCrabyngroRptnQOlDjqBDY4Y5EpI8ta+PZ3BaajKLnIEljiTo1rYjR1Qm 1ibF3odld74nOBA5oJFI+n1MvR5ObMQCAcQ3gKKl1dyZ0EU3Do5E71FqU2cFLu3BuAC7 3nZW/3S6mKzZ4eVsZXD98yL4V9PWIed4WpBNdiae1irsQW+a8C2jw+sCseKWGMf8cFSQ zoZhfIymYY5cx/TFVSiGhqwgQV3qrHaokHgxm4n3h+qBgUgBEn1Sz5blF9ne36hY1UXf MxHmTM7F83XDtXMqXN1tzorm8k9YrNi7Y5S4CP0sxnWulaRiaiUOCp6hatAbll79RFL5 Wg== Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2embdcjeku-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Dec 2017 14:52:30 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vB4EqTh5028742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Dec 2017 14:52:29 GMT Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vB4EqSxi014027; Mon, 4 Dec 2017 14:52:28 GMT In-Reply-To: <87shcrgg8g.fsf@users.sourceforge.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4615.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8734 signatures=668637 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712040217 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:140676 Archived-At: > >> >> As to the error message itself, there isn't really a way > >> >> to distinguish between incomplete and invalid input, > >> > > >> > We do that in some places in the code. > >> > >> What places are those? > > > > In the Lisp code, at least, there are a few places where > > we provide an error that is specific to an invalid regexp. > > Search for handling of standard error `invalid-regexp', > > for instance. >=20 > As far as I can tell, none of those places (apart from isearch.el, the > subject of this bug) try to flag "incomplete" regexps, only invalid or > valid. Isn't that the point? In the case in question the regexp is not incomplete. It is "invalid" because the occurrences count is too high. Showing a message that says it is incomplete is wrong - that was the point of this report. What I cited are cases where we do flag _particular kinds_ of invalid regexps, and so tailor the error msg. That's what could be hoped for in the current case too: ideally, show a msg that says that the occurrences count is too high. If that can't be detected exactly then perhaps we can get close - e.g., invalid occurrences count or some such. > >> > Some code parses the regexp, and that code must know > >> > (or be able to know) both that the regexp is not incomplete > >> > >> What does it mean for a regexp to be incomplete or not? > >> As far as I can tell, the only distinction is that the > >> user means to type more; but the code doesn't know what > >> will happen in the future... > > > > Presumably that term is used only for cases where we can > > be sure that in order for the regexp to be valid there > > would need to be further input. `foo' is not incomplete, > > whether or not the user "means to type more". `[^' is > > incomplete, because it can be made valid only by typing > > more. >=20 > Is `\\{100,20\\}' incomplete? Because it could be made valid > by the user adding a 0 after the 20 to become '\\{100,200\\}'. Of course, a user could always use `M-e' to edit the search pattern and type 0 before the \\}. But our isearch messages don't take that kind of thing into account. They assume the cursor is at the _end_ of the search pattern, so that further input is appended to the pattern. An incomplete-regexp message means (so far, aside from bugs like this one or perhaps cases where Emacs cannot do better) that we expect you to keep typing - at the end of the search pattern, to complete a valid regexp. > Actually, I'm wondering what's the point of isearch showing > "incomplete" instead of the actual regexp invalid error. > I.e., why not instead of >=20 > \ [incomplete] > \{ [incomplete] > \{4 [incomplete] > \{4000 [incomplete] > \{4000\ [incomplete] > \{4000\} >=20 > show this: >=20 > \ [Trailing backslash] > \{ [Unmatched \{] > \{4 [Unmatched \{] > \{4000 [Unmatched \{] > \{4000\ [Trailing backslash] > \{4000\} Feel free to work on that. You might run into some cases that are not so clear-cut. But you might well improve things generally in some way. The problem with that is (I suppose) that it is not, in general, straightforward what would be needed to make the current pattern a valid regexp. In particular, there might be multiple ways to make it valid. Trying to describe what you're expecting, as possible appended input that would make for a valid regexp, would be hard. And doing it accurately, even when feasible, would lead to complex error msgs. It's maybe more user-friendly to just indicate that, so far, the regexp is not valid, but that it could become valid by appending something (i.e., without trying to accurately characterize that something). Anyway, unless working on that is needed or appropriate for fixing the reported bug, that should perhaps be dealt with by a separate bug (enhancement request).