From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#68514: 30.0.50; minibuffer-choose-completion + elisp-c-a-p delete next sexp when completing after open paren Date: Tue, 16 Jan 2024 14:43:35 -0500 Message-ID: References: <86ply1npno.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25259"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: dmitry@gutov.dev, 68514@debbugs.gnu.org, monnier@iro.umontreal.ca To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 16 20:44:22 2024 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 1rPpME-0006Nf-2S for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Jan 2024 20:44:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPpLv-000159-Hd; Tue, 16 Jan 2024 14:44:05 -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 1rPpLu-00014z-Hm for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 14:44:02 -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 1rPpLu-0002Wm-9z for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 14:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPpLu-0003kN-HH for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 14:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Jan 2024 19:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68514 X-GNU-PR-Package: emacs Original-Received: via spool by 68514-submit@debbugs.gnu.org id=B68514.170543422514372 (code B ref 68514); Tue, 16 Jan 2024 19:44:02 +0000 Original-Received: (at 68514) by debbugs.gnu.org; 16 Jan 2024 19:43:45 +0000 Original-Received: from localhost ([127.0.0.1]:49818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPpLc-0003jk-DT for submit@debbugs.gnu.org; Tue, 16 Jan 2024 14:43:44 -0500 Original-Received: from mxout6.mail.janestreet.com ([64.215.233.21]:46807) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPpLZ-0003jW-Q6 for 68514@debbugs.gnu.org; Tue, 16 Jan 2024 14:43:42 -0500 In-Reply-To: <86ply1npno.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 16 Jan 2024 19:39:39 +0200") DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1705434215; bh=k0SNNEA83q/Gj32OV++rkECuHW3TW3uwBCdGFtEqIKI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=O7wY6QMHqtnLhUM3TaxNrxDbII0L5hMBkEdRzEEmlhvH1PFgbqZXFsueoNykUFRyC 6KzeGo0qoIfvmXyr4Q45J9/T+NZb6/KszMYlJSesZlgr6sgUQipH/CBGcVc1TF4bVf ckMiAIBKp5y9qXYwa/EzG3TWFRrwUX5ObkXCmlS0U9VZe8dJeXMxT6U8zEPHDxuJrB dBotnACC4dWoi5KdTKR9250zz5XhXUMZrZ5ZKlffOALUe+3jrWGQ5GZSYR6+vns8+X 7TGeVho2RpzhhYzHR1goq3QyMa9+bqVv1ss0VSxockHgGQ9HLSpKSOB3vsHRL6GV3Z vtlvcFldiEkXA== 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:278361 Archived-At: --=-=-= Content-Type: text/plain Juri Linkov writes: >> This is because elisp-completion-at-point returns a completion region >> covering the entire sexp after the start of the region. That sexp is >> "(progn (some) (big) (expression))" in the first case and "a" in the >> second case. > > This is a known bug without a known fix: > https://debbugs.gnu.org/64903#18 Alright, how about this patch? Should fix most of the issue without changing the code too much. --=-=-= Content-Type: text/x-patch; charset=utf-8 Content-Disposition: inline; filename=0001-Make-elisp-cap-region-cover-a-symbol-not-lists-or-st.patch Content-Transfer-Encoding: quoted-printable >From d76353122ec563eb2d3ca23f96ea67a6843974c5 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 16 Jan 2024 14:32:21 -0500 Subject: [PATCH] Make elisp-cap region cover a symbol, not lists or strings elisp-completion-at-point calculates the completion region by running backward-sexp from (point) and storing that position as the beginning, then running forward-sexp from the beginning and storing that position as the end. elisp-completion-at-point does symbol completion, so the completion region should only cover a symbol. Therefore, elisp-completion-at-point checks whether the beginning of the completion region (the result from backward-sexp) is a quotation mark or open paren, which would indicate that the region covers a string or list, and returns nil in that case. If point is already at the start of a sexp (e.g. immediately after an open paren) then backward-sexp will not move point and the beginning of the completion region would (correctly) be the original point. forward-sexp, in this case, will move over the next sexp after point and include it in the completion region, even if it's a string or list. That has several bad effects: - An unrelated next sexp can be deleted by doing completion at the start of some earlier sexp (bug#64903, bug#68514) - The completion region can be very large, breaking some completion styles; if the next sexp is large enough, completion will fail with:: (invalid-regexp "Regular expression too big") - External completion packages can be broken by this, including corfu: https://github.com/minad/corfu/issues/350 We fix this by mirroring the check on the character at start of the region. We now also check if the character at the end of the completion region is a quotation mark or close paren, and set the end of the region equal to the beginning in that case. This way, we avoid including a string or list in the completion region, but still allow completion to proceed. * lisp/progmodes/elisp-mode.el (elisp-completion-at-point): Avoid returning a completion region which includes a string or list. (bug#64903) --- lisp/progmodes/elisp-mode.el | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index 0ce98ee471c..c9ae92b5680 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -668,6 +668,9 @@ elisp-completion-at-point (goto-char beg) (forward-sexp 1) (skip-chars-backward "'=E2=80=99") + (when (member (char-syntax (char-before (point))) + '(?\" ?\))) + (goto-char beg)) (when (>=3D (point) pos) (point))) (scan-error pos)))) --=20 2.39.3 --=-=-=--