From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.bugs Subject: bug#24914: 24.5; isearch-regexp: wrong error message Date: Mon, 04 Dec 2017 01:27:27 -0500 Message-ID: <87shcrgg8g.fsf@users.sourceforge.net> References: <7c208ac0-8aa2-4db8-a38d-760f91c50500@default> <87h8t7ix7m.fsf@users.sourceforge.net> <87d13visrh.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512368888 16592 195.159.176.226 (4 Dec 2017 06:28:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 06:28:08 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) Cc: 24914@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 04 07:28:05 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 1eLkEV-00045d-Eq for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Dec 2017 07:28:03 +0100 Original-Received: from localhost ([::1]:41383 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLkEc-0006L4-Sb for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Dec 2017 01:28:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLkEX-0006Km-GQ for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 01:28:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLkEU-0000o7-CW for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 01:28:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35517) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLkEU-0000ni-82 for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 01:28:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eLkET-0003QA-IL for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 01:28:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Dec 2017 06:28:01 +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.151236885812845 (code B ref 24914); Mon, 04 Dec 2017 06:28:01 +0000 Original-Received: (at 24914) by debbugs.gnu.org; 4 Dec 2017 06:27:38 +0000 Original-Received: from localhost ([127.0.0.1]:44198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLkE6-0003L0-9D for submit@debbugs.gnu.org; Mon, 04 Dec 2017 01:27:38 -0500 Original-Received: from mail-it0-f47.google.com ([209.85.214.47]:36163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eLkE4-0003J7-PF for 24914@debbugs.gnu.org; Mon, 04 Dec 2017 01:27:37 -0500 Original-Received: by mail-it0-f47.google.com with SMTP id d16so4011509itj.1 for <24914@debbugs.gnu.org>; Sun, 03 Dec 2017 22:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=59HXhpyk+KoLBuuvbpXupfm6sIQkkQ0MjbX00KQVzh4=; b=BdhUBGlXDcW+V/x0Se+9moGZ73DISsTj1kKxbaNOYU/ZZaRRMTG2UV3YYVsyuCRrm6 lj+3mIixleqfVGz/Q7frbJBqOQBzACDv4JY+A8/KoA+Rvjj/qFr+mjA+z8BmnDs1LTKD qg5oA8YG6qn6kr+CaCbJwOk/fC96MJQ2u+IV42fGPzPkir4GIi9y3Gn+0ecuxgsHmn5Z GXdXu5YZgmZ77fUuSiOPaEz3Oi4cv3VAWeCukWDtgjoFyWouwuN8lV2ZC2JtYDqkPKEZ M1Av3ZFQiU4hmZVZkDTEJTV6PFDYtX0WBTo0wZg+OMStzVNVfsqnkRY+S5k1WHQyXZjs pu9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=59HXhpyk+KoLBuuvbpXupfm6sIQkkQ0MjbX00KQVzh4=; b=b2R64pjHEwbtMaNEsAwWsgVqGDD9eG8bCW4OB8P3N9pYkYsWidceOkPdQLHdnEpRDi AP2JCHGerErFfQVljw1KnUGAmaI5KRBrUDELh6A35zbGIuLRpUjk0OGeNKwzzLfeIyyf lX7xwLvUiu2i+JsOx3dpPuP+PioQhdJiDZ+hePfOLRLfKuI21QXH2LAnYNRAxIF73Mwm ZmzoA4rt/qyojvBNKeEbPLvf4zsTtaQOGElQUILEHPYPFNKgBQ7guRayxInRRTtxV5lI G6xbvTp+6EmSG2n5RUxRLzwAGTrp56WNOf5DvNbwE72Pjhsp1EvbUX1XlGFoBf6lMmYe PYjw== X-Gm-Message-State: AKGB3mKFTIAFA5GYdGE9iRmtyxp92jh97F3H2GIYAnKnTDWd5F0mOVXX HIAg9j0PsL+IChEesWjG8/y4tQ== X-Google-Smtp-Source: AGs4zMa7Hf5CFQDq6qxBCCJIDpE51SDDB55XBb8saWIdWMMiTQbA9N8hfB0WbBuoZuHNAbWY4ve2jw== X-Received: by 10.36.22.147 with SMTP id a141mr12039089ita.30.1512368850770; Sun, 03 Dec 2017 22:27:30 -0800 (PST) Original-Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id r190sm5584751iod.7.2017.12.03.22.27.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 03 Dec 2017 22:27:29 -0800 (PST) In-Reply-To: (Drew Adams's message of "Sun, 3 Dec 2017 10:56:32 -0800 (PST)") 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:140673 Archived-At: Drew Adams writes: >> It's not a limit in Lisp, but in regex.c. > > We can't use something larger there? Hmm, right, actually I see in regex.h: /* If sizeof(int) == 2, then ((1 << 15) - 1) overflows. */ #define RE_DUP_MAX (0x7fff) Does Emacs even support 16 bit platforms? >> >> 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. 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. >> > 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. Is `\\{100,20\\}' incomplete? Because it could be made valid by the user adding a 0 after the 20 to become '\\{100,200\\}'. 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 \ [incomplete] \{ [incomplete] \{4 [incomplete] \{4000 [incomplete] \{4000\ [incomplete] \{4000\} show this: \ [Trailing backslash] \{ [Unmatched \{] \{4 [Unmatched \{] \{4000 [Unmatched \{] \{4000\ [Trailing backslash] \{4000\}