From unknown Fri Aug 15 15:59:03 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#67514 <67514@debbugs.gnu.org> To: bug#67514 <67514@debbugs.gnu.org> Subject: Status: 30.0.50; completion preview symbol length calculation should use point Reply-To: bug#67514 <67514@debbugs.gnu.org> Date: Fri, 15 Aug 2025 22:59:03 +0000 retitle 67514 30.0.50; completion preview symbol length calculation should = use point reassign 67514 emacs submitter 67514 Herman, G=C3=A9za severity 67514 normal tag 67514 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 28 15:40:47 2023 Received: (at submit) by debbugs.gnu.org; 28 Nov 2023 20:40:47 +0000 Received: from localhost ([127.0.0.1]:47837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r84sw-00044u-ER for submit@debbugs.gnu.org; Tue, 28 Nov 2023 15:40:47 -0500 Received: from lists.gnu.org ([2001:470:142::17]:35916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r84sd-000432-IY for submit@debbugs.gnu.org; Tue, 28 Nov 2023 15:40:30 -0500 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 1r84sR-0004Tj-5N for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2023 15:40:15 -0500 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r84sM-0005Tg-06 for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2023 15:40:14 -0500 Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-332c7d4a6a7so3957919f8f.2 for ; Tue, 28 Nov 2023 12:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701204006; x=1701808806; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=lZ5jUwSpRUmbuFCv4GaEtDcZURfbA01iRsFoe/PbYr0=; b=Cz5E+WPWtZdt8zfDOFPeJyvihXiTqAM2xHNAP6Guh1Y2kkyeERiyYsOSjZd+U7yavQ xfk498litxovsRYy+ZwmArOyw3yIrykm4YYgbOZI3gYBqiJJfQ3sVKM7EB4OXj2l0QcF 2JUlNkP4vPJUxpbf9JZNPTwyARq2HCCzeE3E/1YfzbtJNcjLh+QyxqJNyZ4evsY5jgR3 IwNljGJLfgrBd4lQRWMAuISMi3XechrNe6m11QOP8PIWwCioFufNlRD85TGjmKr+z1lw sPu50YlYeAtSmQI4KJaxOfpPgDcFaPON4BVf+lbt3O4o9t3o5zcqSTnlylurY+hDUdqv vrvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701204006; x=1701808806; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lZ5jUwSpRUmbuFCv4GaEtDcZURfbA01iRsFoe/PbYr0=; b=JVW5OVesdFLEP459xYVZRX77PtiNcBL/xGIugNveYjjx50Si+XEvRGkezEQmBM6jUy m15hN93e9MJ8ErteUaTTS7zW5zpKYdjK3wQhGGOUxyMsPtQc6tlo44whc9LiLDGA5njC 4lFvxHtofA04OEEWsHMc6CPz+jDJH7efWO/ljtRKCPTMBG7R7n7Z8/LA3K31Fo7Thp52 v5TnvHssYfNa/YRnbACFjzN916323+ABy9MMmk2zdCTfBI7ajZpYeS6bJVQCqXPf3oOR 3143GwhDNf+/bI8CHqD4GYe1yNqB8d4t8+ZlbrE1I9cu0XQryPPxLuQKkxytQWLwkEpg 0MTg== X-Gm-Message-State: AOJu0YxfeqnxHkZ74/P3qRNRXEvhxdhvb1EV3LedS8M3jLEOxt/+ErBM gU63Hlr5AXNx0GysUoVsp0l2LikAKls= X-Google-Smtp-Source: AGHT+IESAYuDxsdmFsUJQVlodFxIm09lH5QL1I2T+gUkxb0xpzoLNUPNGxAx/y6zLMNM0cuUR+y4mg== X-Received: by 2002:adf:e84b:0:b0:333:86d:c28b with SMTP id d11-20020adfe84b000000b00333086dc28bmr3830140wrn.32.1701204006297; Tue, 28 Nov 2023 12:40:06 -0800 (PST) Received: from localhost (netacc-gpn-4-30-169.pool.yettel.hu. [84.224.30.169]) by smtp.gmail.com with ESMTPSA id t8-20020a5d42c8000000b00332fa6cc8acsm8731546wrr.87.2023.11.28.12.40.05 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 12:40:05 -0800 (PST) From: =?utf-8?Q?Herman=2C_G=C3=A9za?= To: bug-gnu-emacs@gnu.org Subject: 30.0.50; completion preview symbol length calculation should use point Date: Tue, 28 Nov 2023 21:39:49 +0100 Message-ID: <87y1ehfw8a.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::42e; envelope-from=geza.herman@gmail.com; helo=mail-wr1-x42e.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) I checked out completion-preview, and so far I like it. There is a thing which maybe can be improved (so this is not a bug report, just a suggestion): it's how completion-preview-require-minimum-symbol-length calculates the length. Currently it just returns the length of the symbol under the cursor. I think it would be better to use the length of the part that actually will be used for completion, because if the point is inside a word, then it should only consider the part between the symbol start end the point. I mean, completion-preview-require-minimum-symbol-length should look something like this: (let ((bounds (bounds-of-thing-at-point 'symbol))) (and bounds (<= completion-preview-minimum-symbol-length (- (point) (car bounds))))) From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 28 16:46:46 2023 Received: (at 67514) by debbugs.gnu.org; 28 Nov 2023 21:46:46 +0000 Received: from localhost ([127.0.0.1]:48384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r85un-0006aU-TZ for submit@debbugs.gnu.org; Tue, 28 Nov 2023 16:46:46 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:38558 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r85um-0006aL-Gk for 67514@debbugs.gnu.org; Tue, 28 Nov 2023 16:46:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1701207995; bh=h+vjMO9DyFOrKXnicGWLYIkKz/gFj3pfYRnTB1rMBbI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ibQNcvhD+70JQltxhhQzIHNPzXLokf5ldl0+W8jKc+WwMx2n1F2Zjgo+aO0+mK58C WeRedU3LlTvnh04Bxvb5768fuMMFAT23oKldF2b49WcL/qV/ZtyGa/ByTpRmfY4xTT iyo2KLEypiqzrzFxAmVOsIxgjPTFvWndXf+gDV6XRJyQ3K2CbNrlDVOR2qdQo49Juy TXqrP9J1kIlmtuJ19NBtflWk1EAxiiYp2OWRmSyn0vDXk4Y/F3nxXnISH5yijgcUmB 3O7N6dGvMIsUCtpHsoxsL2ZjgDF8Zs9RN5nTgT9k0YeysvPnxWDF60Ui7qpsTp6lWl f6VukjjrNZ3yg== From: Eshel Yaron To: =?utf-8?Q?G=C3=A9za?= Herman Subject: Re: bug#67514: 30.0.50; completion preview symbol length calculation should use point In-Reply-To: <87y1ehfw8a.fsf@gmail.com> (Herman@debbugs.gnu.org's message of "Tue, 28 Nov 2023 21:39:49 +0100") References: <87y1ehfw8a.fsf@gmail.com> Date: Tue, 28 Nov 2023 22:46:32 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67514 Cc: 67514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) G=C3=A9za Herman writes: > I checked out completion-preview, and so far I like it. Great. > There is a thing which maybe can be improved (so this is not a bug > report, just a suggestion): it's how > completion-preview-require-minimum-symbol-length calculates the > length. Currently it just returns the length of the symbol under the > cursor. I think it would be better to use the length of the part that > actually will be used for completion, because if the point is inside a > word, then it should only consider the part between the symbol start > end the point. Could you please explain why you consider that preferable? The current behavior is intentional and, unless I'm missing something, correct. `completion-at-point-functions` take into account text that follows point as well as the text that precedes point, and Completion Preview mode works also when you're typing in the middle of a symbol. For example, consider the following text in an Elisp buffer: --8<---------------cut here---------------start------------->8--- (minor --8<---------------cut here---------------end--------------->8--- With point between the opening parenthesis and the letter "m", type "define-". The completion preview displays "-mode" just after "minor", suggesting that you complete to "define-minor-mode". That's because the text after point ("minor", in this case) plays a role too. Best, Eshel From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 28 18:41:29 2023 Received: (at 67514) by debbugs.gnu.org; 28 Nov 2023 23:41:29 +0000 Received: from localhost ([127.0.0.1]:48443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r87hp-0001NZ-9V for submit@debbugs.gnu.org; Tue, 28 Nov 2023 18:41:29 -0500 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:45386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r87hj-0001NI-An for 67514@debbugs.gnu.org; Tue, 28 Nov 2023 18:41:27 -0500 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-40b5155e154so3044015e9.3 for <67514@debbugs.gnu.org>; Tue, 28 Nov 2023 15:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701214869; x=1701819669; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:from:to:cc:subject:date:message-id :reply-to; bh=GNmkoGVr6WKPOHZDNKfoxLlhV/g0AqqKNVF+/hMJI4c=; b=G+27N1Hq/KQlq3wOEvKXc/KFQ5E8GRMp1sH9nmGSLXQJAiHVAtXz5P8XaGK5rAWouX SZDNpZV0c9vdpJ4rt7/NvymdH1T09S74eD/Us58qNQQa1/0yQXbU7/6pQo4icYZkBtlb ZmsBCt2vbGxh/Ddnaj8ZTJ4KVLWhVXKM/L4UzCD9dAqwqp4wd34RovR3KuY/SEdXN06e zA7EX4z7cOdM9fiy2I1ELJ1MzW9q8aHcFzImILOIm/8tgKMZzr8w+RJS7+lpniPSfmBj hCV/9+HSWtiOj4b1pBwh4RD3WgNDPjJXX7zwmkCO0IgHTHbwpKOQS2cqK6oJIwX53FvZ MfBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701214869; x=1701819669; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=GNmkoGVr6WKPOHZDNKfoxLlhV/g0AqqKNVF+/hMJI4c=; b=lCR34Ku6XzP/5HDgzws2du7xU0lCXmRWACTj/gtNip2AUnmetAnffNpoQ4fMMhQIdx UbP9OdAjsRh0K6FPFU5nvDKz/pnnoseHaQOGrNzfsp/u7ju68ET6fuQDsQ/hDiPCfg9D jlYqwi48n5BaiY4273IgrtcXLIWU7wn5Olju3dXsUXlzhywnNZUBAYQV6lVr+GhpftUP eUXXg7U9bgSzJ08GmpSy4Qh42RW3EAWG39S/JXWF6DUdWc6AC90HFjfj0ncE46iq6BWO DL9l3aHuT09rV9CbQKFcuk2DS6YIiypsTFCqErrZuT5ijUZHwFUbb9e/oZG+YzofOt9v cUsw== X-Gm-Message-State: AOJu0Yyg+0w1ZE42fikTbmmzCqHpE7MuEtNvhkrwkIVUCPpbGwKP63Oy VcvlYd/e5OAgrR/DSnvgvn4+9xzJ2MM= X-Google-Smtp-Source: AGHT+IGDpxS6f0voWD4gwZM5rvS4FDKBbXm+W2c+Rdl0KD3xhBjNukcEj6kMG3gObNNLzkYSsgwrYA== X-Received: by 2002:a05:600c:19ca:b0:40b:2aa9:21dd with SMTP id u10-20020a05600c19ca00b0040b2aa921ddmr8670207wmq.4.1701214869216; Tue, 28 Nov 2023 15:41:09 -0800 (PST) Received: from localhost (netacc-gpn-4-30-169.pool.yettel.hu. [84.224.30.169]) by smtp.gmail.com with ESMTPSA id z12-20020a5d640c000000b00332cc7c3aaasm16358010wru.21.2023.11.28.15.41.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 15:41:08 -0800 (PST) References: <87y1ehfw8a.fsf@gmail.com> From: =?utf-8?Q?Herman=2C_G=C3=A9za?= To: Eshel Yaron Subject: Re: bug#67514: 30.0.50; completion preview symbol length calculation should use point Date: Wed, 29 Nov 2023 00:17:42 +0100 In-reply-to: Message-ID: <87edg9bg4s.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67514 Cc: 67514@debbugs.gnu.org, =?utf-8?Q?G=C3=A9za?= Herman X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eshel Yaron writes: > G=C3=A9za Herman writes: > >> There is a thing which maybe can be improved (so this is not a=20 >> bug >> report, just a suggestion): it's how >> completion-preview-require-minimum-symbol-length calculates the >> length. Currently it just returns the length of the symbol=20 >> under the >> cursor. I think it would be better to use the length of the=20 >> part that >> actually will be used for completion, because if the point is=20 >> inside a >> word, then it should only consider the part between the symbol=20 >> start >> end the point. > > Could you please explain why you consider that preferable? The=20 > current > behavior is intentional and, unless I'm missing something,=20 > correct. > `completion-at-point-functions` take into account text that=20 > follows > point as well as the text that precedes point, and Completion=20 > Preview > mode works also when you're typing in the middle of a symbol.=20 > For > example, consider the following text in an Elisp buffer: > > --8<---------------cut=20 > here---------------start------------->8--- > (minor > --8<---------------cut=20 > here---------------end--------------->8--- > > With point between the opening parenthesis and the letter "m",=20 > type > "define-". The completion preview displays "-mode" just after=20 > "minor", > suggesting that you complete to "define-minor-mode". That's=20 > because the > text after point ("minor", in this case) plays a role too. I didn't know about this behavior, it makes sense how it works in=20 emacs-lisp-mode. I tried this feature with lsp-mode (using the=20 clangd language server), and it doesn't play this nicely. Suppose that you have this C code: --8<---------------cut here---------------start------------->8--- int main() { int longVariableName =3D 0; VariableName =3D 1; } --8<---------------cut here---------------end--------------->8--- And the point is at the first character at VariableName. Now,=20 pressing "l" will preview longVariableName, but it doesn't do=20 anything with VariableName, so the buffer looks like=20 l(ongVariableName)VariableName (parentheses are not part of the=20 text, I used them to mark the greyed out part). My suggestion doesn't fix this, it just postpones this problem=20 until I write "lon", and then the same thing will happen. The=20 reason that I suggested this is that I use evil-mode, and I put=20 evil-insert to completion-preview-commands. So whenever I enter=20 insert mode, preview could happen. And a lot of cases, I enter=20 insert mode while the point is at the beginning of some word. So=20 with my suggestion, preview won't be happening, if the point is at=20 the beginning of the word. But currently when I enter insert=20 mode, a random preview will be presented, because completion uses=20 an empty string. Perhaps this is what makes the difference? While=20 emacs-lisp-mode uses the whole word for completion (so my=20 suggestion doesn't make sense in this case), but lsp-mode/clangd=20 uses just part of the word until the point (my suggestion makes=20 some sense in this case)? From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 29 03:56:02 2023 Received: (at 67514) by debbugs.gnu.org; 29 Nov 2023 08:56:02 +0000 Received: from localhost ([127.0.0.1]:48814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8GMT-0007oh-Vh for submit@debbugs.gnu.org; Wed, 29 Nov 2023 03:56:02 -0500 Received: from mail.eshelyaron.com ([107.175.124.16]:52490 helo=eshelyaron.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8GMR-0007oG-Oh for 67514@debbugs.gnu.org; Wed, 29 Nov 2023 03:56:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com; s=mail; t=1701248151; bh=T9GKDDs/ifZBQZT8OfkaxUH1FlQLC7dEBiP3rXcx3TY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=f5JIJIjheTNSEZ0v+jGYFPm8cuYXPmleloRofKTqHbF1oXGt60SICNAXJv5P05Nki mo5R59AX2eKnbo8McODhP0mEf6cQXArrKjmJoAS3TwBuFNoQPbJad9Co3zqPsVgngB taTaQSPOXhAcUshKfIyVbeetih1hxeIN4maE+mXPRO4du1QIrFaipXGMTbSsaZCudE o8AjaA2oS0D6BUu4RUFgoP2u9fVi6UPTFFClpqi89kOQNUNMGUVLYi5cyaLwRNVQ9N U5kcNBmtWccF4akWhZ8cbA+1gOLV3SvgcFqegoJkVyHnbzzb+WIJ8AjomtdhSdF9ue RuaYKANE5fUvA== From: Eshel Yaron To: =?utf-8?Q?G=C3=A9za?= Herman Subject: Re: bug#67514: 30.0.50; completion preview symbol length calculation should use point In-Reply-To: <87edg9bg4s.fsf@gmail.com> (Herman@debbugs.gnu.org's message of "Wed, 29 Nov 2023 00:17:42 +0100") References: <87y1ehfw8a.fsf@gmail.com> <87edg9bg4s.fsf@gmail.com> Date: Wed, 29 Nov 2023 09:55:48 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67514 Cc: 67514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) G=C3=A9za Herman writes: > Eshel Yaron writes: > >> ...`completion-at-point-functions` take into account text that >> follows point as well as the text that precedes point, and Completion >> Preview mode works also when you're typing in the middle of a symbol. >> For example, consider the following text in an Elisp buffer... > > I didn't know about this behavior, it makes sense how it works in > emacs-lisp-mode. I tried this feature with lsp-mode (using the > clangd language server), and it doesn't play this nicely. > > Suppose that you have this C code: > > int main() { > int longVariableName =3D 0; > > VariableName =3D 1; > } > > And the point is at the first character at VariableName. Now, > pressing "l" will preview longVariableName, but it doesn't do > anything with VariableName, so the buffer looks like > l(ongVariableName)VariableName (parentheses are not part of the > text, I used them to mark the greyed out part). 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. > 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. > 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? I'm curious, because perhaps your use case can be solved more directly. > So whenever I enter insert mode, preview could happen. And a lot of > cases, I enter insert mode while the point is at the beginning of some > word. So with my suggestion, preview won't be happening, if the point > is at the beginning of the word. But currently when I enter insert > mode, a random preview will be presented, because completion uses an > empty string. See above. > Perhaps this is what makes the difference? While emacs-lisp-mode uses > the whole word for completion (so my suggestion doesn't make sense in > this case), but lsp-mode/clangd uses just part of the word until the > point (my suggestion makes some sense in this case)? 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. Eshel From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 29 04:56:15 2023 Received: (at 67514) by debbugs.gnu.org; 29 Nov 2023 09:56:15 +0000 Received: from localhost ([127.0.0.1]:48920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8HIl-0001Co-5V for submit@debbugs.gnu.org; Wed, 29 Nov 2023 04:56:15 -0500 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:49238) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r8HIi-0001Ca-Rf for 67514@debbugs.gnu.org; Wed, 29 Nov 2023 04:56:13 -0500 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-40b427507b7so26631415e9.2 for <67514@debbugs.gnu.org>; Wed, 29 Nov 2023 01:56:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701251759; x=1701856559; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:from:to:cc:subject:date:message-id :reply-to; bh=eYSMCp8wKSpjuZDHEy4l9oTj6gSGU2GfC+P/6CK1Or4=; b=JvleZJn7IcF1vCEUuPbCCa3yKWx1KFbcu+UUnDSfzDoxcMuabG6e6DP8rQ5v26iwxF EobmBgpN7S75P04L2Dm+vct3GB++n6ft45KUTIIss/aunoBKJe1aPrgf0lsmkuuFhbgl yrlGiH4C/0db3ZQYzNeo+3Bl+F9EEdb7qONcUnrcmyoLALQoPCVVXtk4/Jr3A8aV5pjF r3pgmNXaq70bxWi4BXxm7Tm0B9M/zmCXoGJlO151nHY3+01kdhWLLdCbA7WSlVaBAIfQ vUq1nhKubGNNroz/tX8bNUY8fROeX5ZhYC3Qo+jcbh6XRAttzsI025bXkdsY+fj/tQgK nS9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701251759; x=1701856559; h=content-transfer-encoding:mime-version:message-id:in-reply-to:date :subject:cc:to:from:references:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=eYSMCp8wKSpjuZDHEy4l9oTj6gSGU2GfC+P/6CK1Or4=; b=RBE5Uyn84DLmXj8Xm7n2DFtKmU5rHwTWa1QFEvIpuNyOYh7bM8vNn5gtfTPs/XrZpt U+VmQZJENeMMW4q4UpWrqQ5ON411tOHfQhrha9TBFSKcBBjBkOlKfOLcWmHVwxcZwsGl bRC8sc3goxEklWai1O1sA4NGOIwddjlKl0W9LMnGzf3lOWheQpiayQ6Qa7E5MTg2VmYq ahTYMyEZN1ERTr4CA6KsY1ZVGKsNAljdBe1E9X5C1z0bo8sACm2k9LirS+Sl/jYd2QRF maztbLJuwI5NrcGjvJSMYvu24h1CQJuB3kdUO7FrQxUhtDtWOoiNxDw7aojPKBR9f2Tm QLtA== X-Gm-Message-State: AOJu0Yy4pegpT3FAil+fiU4CuEIQt84KJ4iecvxM5IL2erZ3CvCQ0jCa KFa0pYowCWphQnsdtSbSoiY= X-Google-Smtp-Source: AGHT+IFYKG/7We3aVNl4INjZ2su68QYi9hhHo2WsJ208bdINdk4Tqz5Z+fYYMKvHeniIRqGP841w9w== X-Received: by 2002:adf:e28a:0:b0:333:950:a1d2 with SMTP id v10-20020adfe28a000000b003330950a1d2mr3407876wri.42.1701251759131; Wed, 29 Nov 2023 01:55:59 -0800 (PST) Received: from localhost (netacc-gpn-4-30-169.pool.yettel.hu. [84.224.30.169]) by smtp.gmail.com with ESMTPSA id d14-20020adff84e000000b00332f6202b73sm11660971wrq.47.2023.11.29.01.55.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Nov 2023 01:55:58 -0800 (PST) References: <87y1ehfw8a.fsf@gmail.com> <87edg9bg4s.fsf@gmail.com> From: =?utf-8?Q?Herman=2C_G=C3=A9za?= To: Eshel Yaron Subject: Re: bug#67514: 30.0.50; completion preview symbol length calculation should use point Date: Wed, 29 Nov 2023 10:06:07 +0100 In-reply-to: Message-ID: <87ttp4evde.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67514 Cc: 67514@debbugs.gnu.org, =?utf-8?Q?G=C3=A9za?= Herman X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eshel Yaron writes: > G=C3=A9za Herman writes: > >> Eshel Yaron writes: >> >>> ...`completion-at-point-functions` take into account text that >>> follows point as well as the text that precedes point, and=20 >>> Completion >>> Preview mode works also when you're typing in the middle of a=20 >>> symbol. >>> For example, consider the following text in an Elisp buffer... >> >> I didn't know about this behavior, it makes sense how it works=20 >> in >> emacs-lisp-mode. I tried this feature with lsp-mode (using the >> clangd language server), and it doesn't play this nicely. >> >> Suppose that you have this C code: >> >> int main() { >> int longVariableName =3D 0; >> >> VariableName =3D 1; >> } >> >> And the point is at the first character at VariableName. Now, >> pressing "l" will preview longVariableName, but it doesn't do >> anything with VariableName, so the buffer looks like >> l(ongVariableName)VariableName (parentheses are not part of the >> text, I used them to mark the greyed out part). > > I see that. I think this is a bug in `lsp-mode`, FWIW. You get=20 > the > same erroneous completion with `completion-at-point` in that=20 > case. > Eglot seems to do the right thing though. Yes, probably it's a bug. Thanks for checking eglot, this means=20 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=20 > discussion > but we can already close this as "notabug", unless you think=20 > otherwise. Sure, feel free to close it. It was just a suggestion in the=20 first place, but in the light of the new information (modes=20 usually use the whole symbol for completion), the current behavior=20 is exactly what we wanted. >> The reason that I suggested this is that I use evil-mode, and I=20 >> put >> evil-insert to completion-preview-commands. > > Note that `completion-preview-commands` is a "list of commands=20 > that > should trigger completion preview", as the docstring says. You=20 > 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=20 > place? In general, I want evil-insert to trigger the preview. Suppose=20 that you started to type something, you got the preview, but then=20 you realize that you forgot something, so (without finishing the=20 word) you move to some other part of the code, and do some=20 modification there. Then you move back to your original position,=20 and go to insert mode to continue typeing. It makes sense that=20 preview is triggered right at the moment when insert mode is=20 activated. (Note: I added other evil commands to completion-preview-commands=20 as well. For example, when I type "cw" in a middle of word, I want=20 to trigger preview, just like if the end of a word deleted by=20 usual emacs commands. I know that kill-word is not on the list=20 currently, but maybe it should be?) > AFAICT `lsp-mode` is giving you inappropriate completion=20 > suggestions, > and I don't think that it's up to Completion Preview mode to fix=20 > that. > Is this problem common among other completion backends? If so=20 > we may > consider adding some measure to circumvent it. But it'd be=20 > better to > improve these backends instead, IMO. I tried scad-mode (this also uses capf), and it works correctly,=20 similarly how emacs-lisp-mode works. So it indeed seems that=20 lsp-mode causes the problem. Thanks for your time! From debbugs-submit-bounces@debbugs.gnu.org Wed Nov 29 16:26:21 2023 Received: (at 67514) by debbugs.gnu.org; 29 Nov 2023 21:26:21 +0000 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 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== From: Eshel Yaron To: =?utf-8?Q?Herman=2C_G=C3=A9za?= Subject: Re: bug#67514: 30.0.50; completion preview symbol length calculation should use point In-Reply-To: <87ttp4evde.fsf@gmail.com> ("Herman, =?utf-8?Q?G=C3=A9za=22's?= message of "Wed, 29 Nov 2023 10:06:07 +0100") References: <87y1ehfw8a.fsf@gmail.com> <87edg9bg4s.fsf@gmail.com> <87ttp4evde.fsf@gmail.com> Date: Wed, 29 Nov 2023 22:26:07 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 67514 Cc: 67514@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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! From unknown Fri Aug 15 15:59:03 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 28 Dec 2023 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator