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#66979: Wrong number of arguments with completion-at-point Date: Tue, 07 Nov 2023 15:13:53 -0500 Message-ID: References: <86il6ef4hc.fsf@mail.linkov.net> <86il6dzbz8.fsf@mail.linkov.net> 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="7266"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66979@debbugs.gnu.org, Juri Linkov To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 07 21:17:53 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 1r0SWH-0001gA-AS for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 07 Nov 2023 21:17:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r0SVp-0007EM-03; Tue, 07 Nov 2023 15:17:25 -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 1r0SVo-0007E5-2W for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 15:17: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 1r0SVn-00015g-Na for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 15:17:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r0SWP-0003uh-QM for bug-gnu-emacs@gnu.org; Tue, 07 Nov 2023 15:18:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Nov 2023 20:18: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.169938823114985 (code B ref 66979); Tue, 07 Nov 2023 20:18:01 +0000 Original-Received: (at 66979) by debbugs.gnu.org; 7 Nov 2023 20:17:11 +0000 Original-Received: from localhost ([127.0.0.1]:43321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0SVa-0003tc-Tw for submit@debbugs.gnu.org; Tue, 07 Nov 2023 15:17:11 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62147) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r0SVY-0003tM-D4 for 66979@debbugs.gnu.org; Tue, 07 Nov 2023 15:17:09 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4B63B100068; Tue, 7 Nov 2023 15:16:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1699388183; bh=bxPiely7MZXbE9PTgkk6d0urgEi60vfRppqgMC1mGsQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=okIJHWjZ+o27Jc9xYm/ilHE0nZPjC7gnK5+ChHCcO04gG5bsc1gj39rHJ+dQMkHC9 1tYMSCGb8I0/aYNzIueLA0Dnmy3RervP7Wp5IzrWQSsSXb9VvtJxdMfb89feApOIfp jQNlJ6zpqBYNOv1iuAe2p+YjHPCnCoZY6fCj2lGlabmC1ajqxOTPH6WgOzCVw+gQvf ZfPs666WWg5Asg6JA6oH4BmS8zXMhGWyZhMKErA0e5107MaFiXOqEMO2y7m01RdThR R3FWQS6mNxvZiimLp1qc2C/aAwKcxbuSXzpgDYbyK71ZdGNjsrknVcJJhCRdIuMLVE +iH5byH4oou2w== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8F568100033; Tue, 7 Nov 2023 15:16:23 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 80FBE12024A; Tue, 7 Nov 2023 15:16:23 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Tue, 7 Nov 2023 19:50:22 +0000") 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:273948 Archived-At: >> 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? >> 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. Stefan