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 20:52:50 -0800 (PST) Message-ID: <3a58fdaf-10c0-42e6-8c74-753ce24b969e@default> 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> <878tehhlwo.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 1512449662 18660 195.159.176.226 (5 Dec 2017 04:54:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Dec 2017 04:54:22 +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 Tue Dec 05 05:54:14 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 1eM5F9-0004Ak-Ci for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Dec 2017 05:54:08 +0100 Original-Received: from localhost ([::1]:46399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eM5FG-00042H-Mj for geb-bug-gnu-emacs@m.gmane.org; Mon, 04 Dec 2017 23:54:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eM5F8-000418-2e for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 23:54:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eM5F4-0004m2-MS for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 23:54:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37567) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eM5F4-0004lq-IK for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 23:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eM5F4-0006hu-3L for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2017 23:54: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: Tue, 05 Dec 2017 04:54: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.151244958625720 (code B ref 24914); Tue, 05 Dec 2017 04:54:02 +0000 Original-Received: (at 24914) by debbugs.gnu.org; 5 Dec 2017 04:53:06 +0000 Original-Received: from localhost ([127.0.0.1]:46247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eM5E8-0006gk-UU for submit@debbugs.gnu.org; Mon, 04 Dec 2017 23:53:06 -0500 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:46885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eM5E6-0006gG-Nr for 24914@debbugs.gnu.org; Mon, 04 Dec 2017 23:53:03 -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 vB54pqtb101522; Tue, 5 Dec 2017 04:52:53 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=h5dKfNyQNTd7IWFoX2Wl2qmM/YvYDJgD60QKgpK3WKE=; b=Q8HmxIZuENZZSQrhDE3y1FpDA4ZGFXewYCHezUTTbFAu9U2kG+XjcpFRyBov0oCVYTpN aOSXIN9D2ToLA14pZK7SURFATYblBYL8RxmjHh2OZ1RXGmh5Qo/WeIfBPE/wdZa+rgDV ms263FjLxrW8hHuVAZPlwx/cBSrnr/FQqpYaPPIWVo4Uo5IOvh1EoCG91WkB3E1S1hf0 +HDF/j5O2RkCPMR8zSJv3DsqM5+eu9ND47kunBzNCJvlJRBUzzZkoPGpeXRU6gz41ZBT YxTojBEbHCCBAonj7W5m2JDtq1yGHmkfsIHmWlQ52p2+UgzUV0CpJQGzlXd00LWu3hlH sw== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2en9pgsqtq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Dec 2017 04:52:53 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vB54qq95018374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Dec 2017 04:52:52 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vB54qpZk002325; Tue, 5 Dec 2017 04:52:52 GMT In-Reply-To: <878tehhlwo.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=8735 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-1712050073 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:140715 Archived-At: > gettext_noop ("Success"),=09/* REG_NOERROR */ > gettext_noop ("No match"),=09/* 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 [^"),=09/* 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"),=09/* 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 */ >=20 > 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. Agreed. Unless Emacs can be sure that in some context one of them really means that the regexp is not complete. If the user can just keep typing to make a valid regexp then an error msg (premature, not yet warranted) typically hurts more than it helps, I think. But if Emacs can't tell that, than sure, why not? Timing can mean a lot also (but depends on the user and how much thinking is going on). It's not great to interrupt immediately with an error msg if the user was still typing. And clearly some of those error conditions do _not_ end up translated as "incomplete input" messages - or they should not, in any case. Clearly someone made a decision about "Trailing backslash", for instance, and it's a very good decision IMO. That's a more useful "the-pattern-is-incomplete" message than just saying "incomplete input". We are not the first to consider the list of error conditions and what to do about this one or that one. That doesn't imply that the judgment made previously is the best one. It does suggest perhaps consulting those who might have made it, or the larger emacs-devel community. The behavior could be completely one-sided one way or the other way. Or it could be any kind of mix in between. It is currently a mix, but obviously not a perfect one - hence this bug report. Which tradeoff is best? > > 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. >=20 > How does it help (compared to the more precise message)? See above. Isearch is incremental: you don't just enter a complete regexp once and for all (as in `grep', for instance. If Emacs jumps the gun with a premature "error" msg, that can be annoying, no? > 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. No, _not_ surely - I think. Many (most? maybe, maybe not) users are not all that positive about using Emacs regexps. They should be able to interact with Isearch regexps interactively, incrementally. And yes, I think that it can be helpful to let a user know that the current pattern is incomplete as a regexp. But hey, users are different. I'd argue that we could add an option, with the default setting the current behavior (as I expect it is those less experienced that the "incomplete" behavior could benefit the most, and those more experience who could benefit most from the specific "invalid" messages). The latter are probably also the ones most likely to try more complicated regexps, which benefit the most, I expect, from precise "invalid" messages. Adding the behavior you propose as an option shouldn't hurt. But even for that you might want to propose it at emacs-devel. There might be people there more familiar with different use cases or who know more about the history of why the current behavior is as it is. Just a suggestion.