From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#65516: 30.0.50; Edebug behavior of signaling errors in &or Date: Sat, 26 Aug 2023 16:39:20 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5863"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 65516@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 26 22:40:19 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qa04x-0001NC-1q for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 26 Aug 2023 22:40:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qa04d-0005cd-Ej; Sat, 26 Aug 2023 16:39:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qa04c-0005cP-7X for bug-gnu-emacs@gnu.org; Sat, 26 Aug 2023 16:39:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qa04b-0003BI-34 for bug-gnu-emacs@gnu.org; Sat, 26 Aug 2023 16:39:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qa04g-0001tn-82 for bug-gnu-emacs@gnu.org; Sat, 26 Aug 2023 16:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 26 Aug 2023 20:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65516 X-GNU-PR-Package: emacs Original-Received: via spool by 65516-submit@debbugs.gnu.org id=B65516.16930823787263 (code B ref 65516); Sat, 26 Aug 2023 20:40:02 +0000 Original-Received: (at 65516) by debbugs.gnu.org; 26 Aug 2023 20:39:38 +0000 Original-Received: from localhost ([127.0.0.1]:43530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qa04I-0001t5-37 for submit@debbugs.gnu.org; Sat, 26 Aug 2023 16:39:38 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33711) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qa04D-0001sl-Rr for 65516@debbugs.gnu.org; Sat, 26 Aug 2023 16:39:36 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B6D2A1000EF; Sat, 26 Aug 2023 16:39:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1693082361; bh=qx+EYvwRmX9K/AvmpPV+ksiYDChD9qcP8FF5OERTsk4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YKKpXNjoJ7lRcUG4jZTvAyXCWx31JBFQJKrgeU/p7H4FvzDPqdJxJPVk+POr/lQpq gL+/QBoKCs68fhZ87VArnbcwv5QvSHyKJRyMkdS2JBwYKnd4to8bMkpeT0Q2fMT/6w HCuImI3XNanoxMuq+sHIfiozZN4+64+Sso6/zgZoKFiUcfximz5+1eeoYgXN0BEgJU uEEuLVkZOkUbWIHP6BE3xCqVYtCoCcUfa5GhX1pdO8+nBIA2PQBF48HJWhd12WAFn+ C2crZrZVZW9vr8VXdxDy+WvXNdbsK1DnKYythIgP5mlSZWKBuL8qVhd3H2LSY6LvL9 kdg78hOPE4jig== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B7FD8100084; Sat, 26 Aug 2023 16:39:21 -0400 (EDT) Original-Received: from alfajor (unknown [72.2.26.42]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 79B0D120247; Sat, 26 Aug 2023 16:39:21 -0400 (EDT) In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Sat, 26 Aug 2023 14:04:22 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268518 Archived-At: > My question is about edebug-no-match. Do you perhaps have an idea what > the reason might be why it ever chooses to signal an error instead of > just throwing no-match? `edebug-no-match` is the only place where we test `edebug-gate`, so if we make it throw to `no-match` it would make `gate` into a no-op. (`gate` doesn't occur explicitly in your example, but it's implicitly present inside other things like `&define`, and hence `def-form`, IIRC). In a sense `gate` is supposed to be a bit like Prolog's "cut", but Edebug isn't quite like Prolog (e.g. it doesn't really do backtracking; it works more like a PEG parser) and similarly its `gate` isn't the same as "cut". See bug#41988 for a case where we didn't want a failure in one "definition form" to be allowed to continue matching in a second branch of an `&or` (tho this was arguably because some of the code executed along the way had side-effects that can't be undone). :-( Stefan