From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#66979: Wrong number of arguments with completion-at-point Date: Tue, 7 Nov 2023 23:07:00 +0000 Message-ID: References: <86il6ef4hc.fsf@mail.linkov.net> <86il6dzbz8.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35102"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, 66979@debbugs.gnu.org, Juri Linkov To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 08 00:07:45 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 1r0VAe-0008sr-SQ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Nov 2023 00:07:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0VAN-0005uV-Hs; Tue, 07 Nov 2023 18:07:27 -0500 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 1r0VAK-0005u5-Iy for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 18:07:24 -0500 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 1r0VAK-0005yY-2s for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 18:07:24 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r0VAv-00034J-Ux for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 18:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 23:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66979 X-GNU-PR-Package: emacs Original-Received: via spool by 66979-submit@debbugs.gnu.org id=B66979.169939847011778 (code B ref 66979); Tue, 07 Nov 2023 23:08:01 +0000 Original-Received: (at 66979) by debbugs.gnu.org; 7 Nov 2023 23:07:50 +0000 Original-Received: from localhost ([127.0.0.1]:43726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0VAj-00033t-S2 for submit@debbugs.gnu.org; Tue, 07 Nov 2023 18:07:50 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:43811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0VAg-00033f-ST for 66979@debbugs.gnu.org; Tue, 07 Nov 2023 18:07:48 -0500 Original-Received: (qmail 20956 invoked by uid 3782); 8 Nov 2023 00:07:01 +0100 Original-Received: from acm.muc.de (p4fe15714.dip0.t-ipconnect.de [79.225.87.20]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 08 Nov 2023 00:07:01 +0100 Original-Received: (qmail 23376 invoked by uid 1000); 7 Nov 2023 23:07:00 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de 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:273951 Archived-At: Hello, Stefan. On Tue, Nov 07, 2023 at 15:13:53 -0500, Stefan Monnier wrote: > >> commit f931cebce76d911dfc61274e0a8c1de3627b9179 > >> Author: Alan Mackenzie > >> Date: Wed Sep 20 15:51:17 2023 +0000 > >> Insert symbol `debug' into two condition-case handlers > >> This fixes bug#65622. Also correct a mismatch between a > >> function to which advice is added, and that from which it is > >> removed. > >> * lisp/emacs-lisp/macroexp.el (internal-macroexpand-for-load): > >> Add a `debug' to the condition-case handler for `error', so > >> that a useful backtrace will be produced on a macro expansion > >> error. > >> * lisp/progmodes/elisp-mode.el (elisp--local-variables): Add > >> `debug' to a condition-case handler, as above. In the > >> advice-remove call, give the same function, macroexpand-1, as > >> in the corresponding advice-add call. > >> Alan do you remember why you also added the `debug` to the > >> condition-case in `elisp--local-variables`? > >> The rest of the commit looks right to me. > > I was trying to debug an error in eager macro expansion (i.e. macro > > expansion in forms called directly by read), and that was the > > condition-case that was suppressing the backtrace. > Really? I'd expect this case to go through the `condition-case` that's > in `internal-macroexpand-for-load` but not the condition-case that's in > `elisp--local-variables`. > Any chance you can still reproduce the bug and get a backtrace showing > how `elisp--local-variables` gets involved? It's difficult, no I can't get the backtrace, it is being suppressed by some condition-case somewhere. But I do get the error message "Ignoring macroexpansion error: (void-function edebug-after)". That "Ignoring macroexpansion error" comes from elisp--local-variables. To get this, from a reasonably up to date master: (i) git checkout 1d46bca1^. (ii) make -j bootstrap. (iii) Follow the recipe in bug #65622, including (setq debug-on-error t). (iv) Repeat the C-u C-M-x in the recipe several times, until it no longer outputs a backtrace. The message one now sees in the echo area is the "Ignoring macroexpansion error:" one. What has happened is that the advice macroexpand-advice in elisp--local-variables has been applied to macroexpand-1, and due to the typo there, never gets removed (now fixed with bug #65622). This piece of advice is what suppresses the backtrace. > >> Macro expansion errors in there are perfectly normal since > >> `elisp--local-variables` routinely passes incomplete code to > >> macroexpand. IOW most errors signal'd in there probably don't need to > >> be debugged at all. > > But when somebody has set debug-on-error to t, they _want_ those errors > > signalled, surely? > No, I have it set and don't want to be told that the internal completion > machinery extracted broken code from the current buffer in its > best-effort attempt to compute the set of surrounding lexical variables. > In 99% of the cases, it is neither a bug in the code I'm editing nor in > the macros. The design of `elisp--local-variables` is such that it > often builds syntactically invalid code to pass to the macro expander. Which is anything but obvious from the (lack of) comments around that condition case, and in the function in general. But I think I added the debug to that condition-case handler before spotting and correcting the typo in macroexpand[-1]. So it may well be that that debug could be removed without great damage. > Stefan -- Alan Mackenzie (Nuremberg, Germany).