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: Tue, 5 Dec 2017 07:31:21 -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> <87h8t6gegl.fsf@users.sourceforge.net> <878tehhlwo.fsf@users.sourceforge.net> <3a58fdaf-10c0-42e6-8c74-753ce24b969e@default> <87609lgv8r.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 1512487951 2677 195.159.176.226 (5 Dec 2017 15:32:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 5 Dec 2017 15:32:31 +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 16:32:20 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 1eMFCg-0008Sx-Jf for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Dec 2017 16:32:14 +0100 Original-Received: from localhost ([::1]:50336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMFCn-0007X3-Qt for geb-bug-gnu-emacs@m.gmane.org; Tue, 05 Dec 2017 10:32:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39600) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMFCZ-0007RH-0B for bug-gnu-emacs@gnu.org; Tue, 05 Dec 2017 10:32:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMFCT-0004B0-Vn for bug-gnu-emacs@gnu.org; Tue, 05 Dec 2017 10:32:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39363) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eMFCT-0004Ak-Rl for bug-gnu-emacs@gnu.org; Tue, 05 Dec 2017 10:32:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eMFCT-0004Nv-LB for bug-gnu-emacs@gnu.org; Tue, 05 Dec 2017 10:32:01 -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 15:32: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.151248789316820 (code B ref 24914); Tue, 05 Dec 2017 15:32:01 +0000 Original-Received: (at 24914) by debbugs.gnu.org; 5 Dec 2017 15:31:33 +0000 Original-Received: from localhost ([127.0.0.1]:48044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMFC1-0004NE-2e for submit@debbugs.gnu.org; Tue, 05 Dec 2017 10:31:33 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:24813) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMFBz-0004N1-42 for 24914@debbugs.gnu.org; Tue, 05 Dec 2017 10:31:31 -0500 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vB5FVOJp002460 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Dec 2017 15:31:25 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vB5FVN6u030458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Dec 2017 15:31:24 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id vB5FVNuM017712; Tue, 5 Dec 2017 15:31:23 GMT In-Reply-To: <87609lgv8r.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-Source-IP: userv0021.oracle.com [156.151.31.71] 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:140727 Archived-At: > > 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". >=20 > Right, but I can't see why the same shouldn't apply to > "Unmatched \\{" and all the others. Treating them all the same is one possibility. Not the best one, I think, but one possibility. > > 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. >=20 > That code seems to have been there since 1992 "Initial > revision", so it's not clear what, if any, considerations > were made. It might not be clear, but that doesn't mean there weren't good reasons for that judgment. (And no, I'm not saying that a different judgment can't be made now.) And certainly some of those around then, including deciders probably, are still around today. Perhaps RMS has an opinion or recollection about this? > > 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? >=20 > We already get an "error" message, it says "incomplete". > The question is why shouldn't it instead say *why* it's > incomplete. I thought your proposal was to, in all cases, eliminate saying it is incomplete in favor of the specific regexp-invalidity error text. Such error text does not, generally and directly, tell users that the input is incomplete. Users very familiar with regexps might understand that such a msg implies that input is incomplete, but not everyone will get that. > > Adding the behavior you propose as an option shouldn't > > hurt. >=20 > It hurts, because it adds yet another option, which makes a user's job > of going through them and deciding which ones make sense that much > harder (yes, just this particular addded option won't make much > difference, but still). Users who are very familiar with Emacs regexps will be the ones to benefit most from the specific regexp-validity msgs, IMO. They should have no problem customizing an option. Users unfamiliar with Emacs or Emacs regexps will get the simpler default behavior: your input pattern is not yet complete. If you feel strongly about this and are opposed to adding a user option, consider proposing the change you want to emacs-devel. This particular bug is about one case: just the particular "incomplete input" message case cited. Fixing this bug shouldn't require changing the basic behavior, though that is certainly one possibility. You apparently think there is never any value in telling users that the input pattern is not complete as a regexp. I disagree. We apparently agree that at least in some cases the specific regexp-invalidity message is more helpful. There is a spectrum of possibilities here. I see no special reason why the right approach should be all or none. > > 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. >=20 > I hope so.