From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov 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 19:28:39 +0200 Message-ID: <3e453670-b669-4b87-835e-a2e199736fab@gutov.dev> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14858"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: juri@linkov.net To: Spencer Baugh , 68514@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 16 18:29:21 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 1rPnFX-0003bd-JZ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Jan 2024 18:29:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPnFI-0008IV-6S; Tue, 16 Jan 2024 12:29:04 -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 1rPnFG-0008I8-6B for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 12:29: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 1rPnFF-0005nj-UT for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 12:29:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPnFG-0001YK-1v for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 12:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Jan 2024 17:29: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.17054261335952 (code B ref 68514); Tue, 16 Jan 2024 17:29:02 +0000 Original-Received: (at 68514) by debbugs.gnu.org; 16 Jan 2024 17:28:53 +0000 Original-Received: from localhost ([127.0.0.1]:49666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPnF6-0001Xw-Pq for submit@debbugs.gnu.org; Tue, 16 Jan 2024 12:28:53 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:56169) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPnF3-0001Xh-FV for 68514@debbugs.gnu.org; Tue, 16 Jan 2024 12:28:50 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 715F15C021D; Tue, 16 Jan 2024 12:28:43 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 16 Jan 2024 12:28:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705426123; x=1705512523; bh=PYRRXBg9pryibeHD6NsSOn+wqJTymrnK1e2E+fhWOtA=; b= grKZ2uuc1O2ZSyTScpVHWtIgypJOIdYRykZX3ETRfbTqHv3Rm0dGWu3M2Uh3Pob1 FcvHiYc8OPd2FMEc/nm1PQJ6R8YKkDe8dnXAf4vAkMoCFfEL8vLXg+Rb0hzXaXIy wlI9W/l8XTFFTorJtyLRjyQl+qa1e0nDEa5yOLcrA6/jwfjEWQuk961PO8j+z87b a/J7F5C9kGx7xu6t1oiO0gvpu0lo5iNympA6mIISHNaZCZsTFcUpzHJxqHlhEgOs Q67dSXgKWU6WqIV7gJyU6eHA1YW1H9fvg8vYHvXOtjeZ0v0PFbsGij3UGq8k/+Q0 ngGI/2kUuhBrakJS1wbqsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705426123; x= 1705512523; bh=PYRRXBg9pryibeHD6NsSOn+wqJTymrnK1e2E+fhWOtA=; b=S ewAmuhOv6tuwChd3dkkkp8Ed3msgDFbB7M/ISJ3hGkS6cakeqnH/oBcUHoWog1Tp T3puY7zFAYfQ5/3oJiMW0wAd/fPPI2BTBFoUVMkXSkx8K+ikfyTuYCbF86o9Kk4d nnyKKGSN+R1+4XXehALnnyRiCZhR1ohi4XUQz0xt9kz2Tg0imLKPW0yR4jJR5JG1 irCYagBtJ7zo8ydXw4cIt41offo8lJvwpjXAvBAAmmxR/wivz4lAYLcxdzmP/Icq sSXwNJ+cumsEZqfU0CEKArRvRhO3qMMuaINuEG1SGjCdWc3MGB+xEIH4HtFic73L wepXKFn583b9aDYRyhuyw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejfedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeetudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveeg udejheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Jan 2024 12:28:42 -0500 (EST) Content-Language: en-US In-Reply-To: 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:278352 Archived-At: On 16/01/2024 19:06, Spencer Baugh wrote: > I'm not sure how to fix this. I don't know all the features of > elisp-completion-at-point, but maybe it shouldn't use (forward-sexp 1) > when finding the end of the completion region. Maybe it should be doing > something like (skip-syntax-forward "w_") to determine the end of the > region? > > BTW, this completion region returned by elisp-completion-at-point also > causes a bug in company-mode: since company-capf stops completion when > the end of the completion region is after point, it's not possible to do > Elisp company completion immediately after an open paren no matter how > company is configured. I don't have a patch to suggest at the moment, but `elisp-completion-at-point` is indeed peculiar in its bounds detection logic. The idea to use (skip-syntax-forward "w_") sounds good. But one alternative (in case you find it more convenient) is to use (bounds-of-thing-at-point 'symbol).