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 22:51:51 -0500 Message-ID: <878tehhlwo.fsf@users.sourceforge.net> References: <7c208ac0-8aa2-4db8-a38d-760f91c50500@default> <87h8t7ix7m.fsf@users.sourceforge.net> <87d13visrh.fsf@users.sourceforge.net> <87shcrgg8g.fsf@users.sourceforge.net> <87h8t6gegl.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512446196 3216 195.159.176.226 (5 Dec 2017 03:56:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Dec 2017 03:56:36 +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 Tue Dec 05 04:56:32 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 1eM4LM-0000TE-Vf for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Dec 2017 04:56:29 +0100 Original-Received: from localhost ([::1]:46285 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eM4LU-0007xq-8h for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Dec 2017 22:56:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eM4I8-0005Kf-Lu for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 22:53:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eM4I4-0000xm-Mi for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 22:53:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37557) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eM4I4-0000xc-Ib for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 22:53:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eM4I4-0005Mq-36 for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 22:53:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 05 Dec 2017 03: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.151244592220565 (code B ref 24914); Tue, 05 Dec 2017 03:53:02 +0000 Original-Received: (at 24914) by debbugs.gnu.org; 5 Dec 2017 03:52:02 +0000 Original-Received: from localhost ([127.0.0.1]:46238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eM4H4-0005LZ-3U for submit@debbugs.gnu.org; Mon, 04 Dec 2017 22:52:02 -0500 Original-Received: from mail-it0-f51.google.com ([209.85.214.51]:38985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eM4H2-0005L7-5S for 24914@debbugs.gnu.org; Mon, 04 Dec 2017 22:52:00 -0500 Original-Received: by mail-it0-f51.google.com with SMTP id 68so12016612ite.4 for <24914@debbugs.gnu.org>; Mon, 04 Dec 2017 19:52:00 -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=ynpsIQRrviOLooS2MBdRcvP2D74xe3UcQZEklNZSDtI=; b=CHsmYfsKV5+IbM25wA3McNqdi/vBG0/CWoHtCFl268m7RjMa4Jn+e8uCG90IqmUqJT wZYnoS+mIwtlNi/cB/8Elf7yj9KcCMDgVnR8ZKdDJoGYD0fDwRrDeXtphgmDiNDBPwN2 27zkZid0wy+vbCgQ6uFA84NsduaZOPXIhc9IMsdMp1nY2G+miWJQol7KxUmrXvDB8rjc AcT+9rLB6GuF/snftojpVdRtK0mbNg2Fogq4UasaUYzq45ArrH5hpdzMXwblq6Rp8LL0 VJP8OHu9sLRXM4u2zjfy9VvlV3b8SiE7VHFYA8u/8W2hsloBlGJqivvbwSzhS/1r/p7K TkcA== 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=ynpsIQRrviOLooS2MBdRcvP2D74xe3UcQZEklNZSDtI=; b=P/sCX3j5EhzIE1n0YFJVjdJRyzNuJcTz+ebhv2IyeIAPJ4lOak1ZPb/5I4Gttqag5S Uisve04CqQQHKb/7xNgtVlk5xPR2NpmS+OHvKoXmNt+/kCyJXjIVeKJNYlCNAgk5mMWs L2/YpGPFrKnrtZ7XEd9KsXDDdp/Z+4PcQzRTgaaBUjNcxoXh0OC7zwjCP/usxIp7hKsY bJH8SDrVTgdk5BSGjCyneTH8pIbDT6dJEQhVVPpEZA3ZVcrAop4vXHYXpR/HOEqHER7m zbu0BXZ/v5LBrQP94Bhn7lXWhk3OpMj35WhZeq8rCBwDUubYXMwY9mDyw2DPq0rizg+j mYUg== X-Gm-Message-State: AKGB3mJ0/9FcUUdtF7Jd1SXQSZrZWEnexXW9twubSGkqYhYFsEdeklNP Nq1czPVBICVflftK6eQvFsuArA== X-Google-Smtp-Source: AGs4zMbm/RdXPpv7VYniNpvtTZf0M2rizwKeWHrV+x2jPGxuuKzMy97Tu5qsoYBWzFSj3Q06Q6na4Q== X-Received: by 10.107.16.86 with SMTP id y83mr18640453ioi.107.1512445914130; Mon, 04 Dec 2017 19:51:54 -0800 (PST) Original-Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id l4sm6498641ioc.69.2017.12.04.19.51.52 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Dec 2017 19:51:53 -0800 (PST) In-Reply-To: (Drew Adams's message of "Mon, 4 Dec 2017 19:15:42 -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:140714 Archived-At: Drew Adams writes: > I was citing what I thought were such cases in the current > isearch.el code - cases where we do not just say "Invalid > Regexp". We say things like this: > > Too many words > Too many spaces for whitespace matching In that case, the regexp is constructed by Emacs on behalf of the user, so it makes sense to translate the error message so that it matches the user operation. > Unmatched [ or [^ AFAICT, the isearch.el code doesn't write that message, but rather reads it. > Granted, the last is used only in `isearch-query-replace. > > My point was that in some existing cases (not many, > admittedly), we do try to give a more precise error > message when signal `invalid-regexp' is detected. > > But I'm not sure what you're arguing, if you are arguing. The C regex code produces the following error messages when parsing regexps: { gettext_noop ("Success"), /* REG_NOERROR */ gettext_noop ("No match"), /* REG_NOMATCH */ gettext_noop ("Invalid regular expression"), /* REG_BADPAT */ gettext_noop ("Invalid collation character"), /* REG_ECOLLATE */ gettext_noop ("Invalid character class name"), /* REG_ECTYPE */ gettext_noop ("Trailing backslash"), /* REG_EESCAPE */ gettext_noop ("Invalid back reference"), /* REG_ESUBREG */ gettext_noop ("Unmatched [ or [^"), /* REG_EBRACK */ gettext_noop ("Unmatched ( or \\("), /* REG_EPAREN */ gettext_noop ("Unmatched \\{"), /* REG_EBRACE */ gettext_noop ("Invalid content of \\{\\}"), /* REG_BADBR */ gettext_noop ("Invalid range end"), /* REG_ERANGE */ gettext_noop ("Memory exhausted"), /* REG_ESPACE */ gettext_noop ("Invalid preceding regular expression"), /* REG_BADRPT */ gettext_noop ("Premature end of regular expression"), /* REG_EEND */ gettext_noop ("Regular expression too big"), /* REG_ESIZE */ gettext_noop ("Unmatched ) or \\)"), /* REG_ERPAREN */ gettext_noop ("Range striding over charsets"), /* REG_ERANGEX */ }; When doing isearch-*-regexp, most of those errors are converted into "incomplete" (i.e., *less* precise). But I think it would be more helpful to show the original error message. > But I don't think it follows that it would be more helpful to > most users to show the invalid-regexp description in cases > where Emacs can really tell that the input is necessarily > incomplete. I suspect that it is quite common for that > "incomplete input" message to be helpful. How does it help (compared to the more precise message)? Seems to me that telling the user they haven't finished entering the regexp isn't especially helpful; surely the user already knows they haven't finished typing yet.