unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dmitry@gutov.dev>
To: "João Távora" <joaotavora@gmail.com>
Cc: 72705@debbugs.gnu.org
Subject: bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much
Date: Sun, 25 Aug 2024 18:56:06 +0300	[thread overview]
Message-ID: <daf75afd-cb29-4324-8b2b-60ae547e7f06@gutov.dev> (raw)
In-Reply-To: <874j79vshl.fsf@gmail.com>

On 25/08/2024 12:53, João Távora wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> On 23/08/2024 13:23, João Távora wrote:
>>
>> I see what you're saying, but insofar that current completion is
>> mostly working out well, adding the special logic for parens would
>> improve a lot of cases, and keep others the same degree of broken (the
>> email-sending ones, for sure). So it might be worth a try.
> 
> No, it's not.  It's the kind of complexity Eglot isn't after.  It's a
> losing game with the growing number of servers who aren't bound by these
> rules in any way.
> 
>> Anyway, stopping any partial completion (at first I didn't understand
>> that you meant a more general notion that the partial-completion
>> c-style) should be similarly easy to what the current patch does. You
>> would just drop the second clause in eglot--dumb-tryc, I think. Or
>> maybe both the first and the second.
> 
> If it's easy, then we should definitely do it.

The corresponding change probably looks like this:

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 844fc634be9..fcf4e586ead 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -3147,20 +3147,10 @@ eglot--dumb-flex

  (defun eglot--dumb-allc (pat table pred _point) (funcall table pat 
pred t))
  (defun eglot--dumb-tryc (pat table pred point)
-  (let ((probe (funcall table pat pred nil)))
-    (cond ((eq probe t) t)
-          (probe
-           (if (and (not (equal probe pat))
-                    (cl-every
-                     (lambda (s) (string-prefix-p probe s 
completion-ignore-case))
-                     (funcall table pat pred t)))
-               (cons probe (length probe))
-             (cons pat point)))
-          (t
-           ;; Match ignoring suffix: if there are any completions for
-           ;; the current prefix at least, keep the current input.
-           (and (funcall table (substring pat 0 point) pred t)
-                (cons pat point))))))
+  ;; Match ignoring suffix: if there are any completions for
+  ;; the current prefix at least, keep the current input.
+  (and (funcall table (substring pat 0 point) pred t)
+       (cons pat point)))

  (add-to-list 'completion-category-defaults '(eglot-capf (styles 
eglot--dumb-flex)))
  (add-to-list 'completion-styles-alist '(eglot--dumb-flex 
eglot--dumb-tryc eglot--dumb-allc))


But I'd prefer to hold off on it until specific issues come up.

>> This works:
>>
>>    (when (buffer-live-p "*Completions*")
>>      (kill-buffer "*Completions*"))
>>    (completion-at-point)
>>    (should (looking-back "foo"))
>>    (should (looking-at "123"))
>>    (should (get-buffer "*Completions*"))
>>
>> Is that better?
> 
> It's half-decent, I think.  Please use that.

Okay.

>> 1) Completions are not filtered by suffix, ever.
>> 2) Completing count_ones() does not delete the suffix ("1234"
>> remains).
> 
> Interesting, I thought deleting the 1234 was part of the edit, but the
> user of that bug report was after some Emacs specific behaviour.
> Anyway, I don't think the test is too brittle, and I think I'd like to
> know anyway if something about that breaks anyway.  Maybe you can just
> add a comment saying ";; this test might be a bit too brittle, but
> interesting nonetheless".

Pushed to emacs-30 as two parts: new tests for existing behavior and the 
fix with its own tests (096730510cd, 713069dd7a8).





  reply	other threads:[~2024-08-25 15:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19  1:51 bug#72705: 31.0.50; eglot--dumb-tryc Filters out too much Dmitry Gutov
2024-08-19  9:22 ` João Távora
2024-08-19 11:39   ` Dmitry Gutov
2024-08-19 12:59     ` João Távora
2024-08-20  2:08       ` Dmitry Gutov
2024-08-20  9:40         ` João Távora
2024-08-21  0:30           ` Dmitry Gutov
2024-08-21 16:52             ` João Távora
2024-08-22  0:41               ` Dmitry Gutov
2024-08-22 16:59                 ` João Távora
2024-08-22 23:16                   ` Dmitry Gutov
2024-08-23 10:23                     ` João Távora
2024-08-25  2:49                       ` Dmitry Gutov
2024-08-25  9:53                         ` João Távora
2024-08-25 15:56                           ` Dmitry Gutov [this message]
2024-08-25 23:40                           ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=daf75afd-cb29-4324-8b2b-60ae547e7f06@gutov.dev \
    --to=dmitry@gutov.dev \
    --cc=72705@debbugs.gnu.org \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).