From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67514: 30.0.50; completion preview symbol length calculation should use point Date: Wed, 29 Nov 2023 22:26:07 +0100 Message-ID: References: <87y1ehfw8a.fsf@gmail.com> <87edg9bg4s.fsf@gmail.com> <87ttp4evde.fsf@gmail.com> Reply-To: Eshel Yaron Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29373"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 67514@debbugs.gnu.org To: Herman@debbugs.gnu.org, =?UTF-8?Q?G=C3=A9za?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 29 22:29:48 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 1r8S7v-0007Qy-Ei for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 29 Nov 2023 22:29:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r8S5A-0001zi-Cv; Wed, 29 Nov 2023 16:26:56 -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 1r8S59-0001yW-16 for bug-gnu-emacs@gnu.org; Wed, 29 Nov 2023 16:26:55 -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 1r8S58-00053p-Oq for bug-gnu-emacs@gnu.org; Wed, 29 Nov 2023 16:26:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r8S5G-0000fQ-4G for bug-gnu-emacs@gnu.org; Wed, 29 Nov 2023 16:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eshel Yaron Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 29 Nov 2023 21:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67514 X-GNU-PR-Package: emacs Original-Received: via spool by 67514-submit@debbugs.gnu.org id=B67514.17012931812508 (code B ref 67514); Wed, 29 Nov 2023 21:27:02 +0000 Original-Received: (at 67514) by debbugs.gnu.org; 29 Nov 2023 21:26:21 +0000 Original-Received: from localhost ([127.0.0.1]:51608 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8S4a-0000eM-LM for submit@debbugs.gnu.org; Wed, 29 Nov 2023 16:26:21 -0500 Original-Received: from mail.eshelyaron.com ([107.175.124.16]:56274 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8S4Y-0000eB-MY; Wed, 29 Nov 2023 16:26:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1701293170; bh=efS0Z+RTNHUB9AoD91AUEWbTlPeRJDCg+FmzOtOhC5A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gv/qYOWqDjaGeJYqragI+gikgvV1jI5LdKcwXltsVHVMskLnmcdeva+09DZbTCdju NWkvngCs3cCVPVOzLAZAzITpRS6m2bSGpF+FoPMFXjQvHk0/PZyEojKKlgESTeEIcO GKHUNH4A4umqQGjvAGEjC0fMBMs8FlZgMuJ0sZfyluKUzkao9ix7HPJEpdjKaFeRBU 0txDJapFqDXhzcdY8jnrlQZV0x157zZ7mu8pjSUlxh0VfH3K8idxiBpJIBE057TKy9 H5e8NmY518yh4SkamVQ9OB2Ccua58MIcGQbh0d2U12SkpP7TrgzJkNa4BLB+cmM2bF 4BhOJJ4CZ9JWw== In-Reply-To: <87ttp4evde.fsf@gmail.com> ("Herman, =?UTF-8?Q?G=C3=A9za?="'s message of "Wed, 29 Nov 2023 10:06:07 +0100") 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:275258 Archived-At: tags 67514 notabug close 67514 thanks G=C3=A9za Herman writes: > Eshel Yaron writes: > >> G=C3=A9za Herman writes: >> >>> ...I tried this feature with lsp-mode (using the clangd language >>> server), and it doesn't play this nicely... >> >> I see that. I think this is a bug in `lsp-mode`, FWIW. You get the >> same erroneous completion with `completion-at-point` in that case. >> Eglot seems to do the right thing though. > > Yes, probably it's a bug. Thanks for checking eglot, this means that > the behavior comes from lsp-mode, not from clangd. > >>> My suggestion doesn't fix this, it just postpones this problem >>> until I write "lon", and then the same thing will happen. >> >> Indeed. What follows is a tangent, I'm happy to continue the >> discussion but we can already close this as "notabug", unless you >> think otherwise. > > Sure, feel free to close it. It was just a suggestion in the first > place, but in the light of the new information (modes usually use the > whole symbol for completion), the current behavior is exactly what we > wanted. Great. So this message should close the bug, unless there're some permissions required to do that, in which case we'll ask someone else to help with it. >>> The reason that I suggested this is that I use evil-mode, and I put >>> evil-insert to completion-preview-commands. >> >> Note that `completion-preview-commands` is a "list of commands that >> should trigger completion preview", as the docstring says. You seem >> to indicate below that you often want `evil-insert` not to trigger >> completion preview, so why add it to this list in the first place? > > In general, I want evil-insert to trigger the preview. Suppose that > you started to type something, you got the preview, but then you > realize that you forgot something, so (without finishing the word) you > move to some other part of the code, and do some modification there. > Then you move back to your original position, and go to insert mode to > continue typeing. It makes sense that preview is triggered right at > the moment when insert mode is activated. I see, that makes sense. I'm not sure that this is the most common preference, but I think it's definitely a valid use case. It relates to a broader question, of whether we should provide more flexibility for specifying the conditions in which the preview should appear. In this case, ISTM that current implementation should get you covered (barring such misbehaving capfs). If you find other cases in which more nuanced control over when the preview appears would be helpful, I'd be interested to hear about it. > (Note: I added other evil commands to completion-preview-commands as > well. For example, when I type "cw" in a middle of word, I want to > trigger preview, just like if the end of a word deleted by usual emacs > commands. I know that kill-word is not on the list currently, but > maybe it should be?) Maybe, it's kind of hard to be exhaustive with this list, so we went with only the minimum needed to provide a useful experience by default. `kill-word` and `backward-kill-word` are good candidates, but OTOH it's easy enough for users to add them if they want to. >> AFAICT `lsp-mode` is giving you inappropriate completion suggestions, >> and I don't think that it's up to Completion Preview mode to fix >> that. Is this problem common among other completion backends? If so >> we may consider adding some measure to circumvent it. But it'd be >> better to improve these backends instead, IMO. > > I tried scad-mode (this also uses capf), and it works correctly, > similarly how emacs-lisp-mode works. So it indeed seems that lsp-mode > causes the problem. > > Thanks for your time! Thank you!