From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list Date: Sun, 19 Feb 2023 18:19:02 +0000 Message-ID: References: <87ttzn6kxb.fsf@thornhill.no> <875yby62j9.fsf@thornhill.no> <348D7924-284D-4D14-882E-02C8CAD7A925@thornhill.no> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000652ada05f511953d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30479"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61532@debbugs.gnu.org To: Theodor Thornhill , Stefan Monnier , Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 19 19:20:24 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 1pToIS-0007kC-1x for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 19 Feb 2023 19:20:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pToI8-0005Tz-Oq; Sun, 19 Feb 2023 13:20: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 1pToI6-0005S3-VJ for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 13:20:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pToI6-0003ck-Mc for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 13:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pToI6-0007UC-Il for bug-gnu-emacs@gnu.org; Sun, 19 Feb 2023 13:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 19 Feb 2023 18:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61532 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 61532-submit@debbugs.gnu.org id=B61532.167683076028714 (code B ref 61532); Sun, 19 Feb 2023 18:20:02 +0000 Original-Received: (at 61532) by debbugs.gnu.org; 19 Feb 2023 18:19:20 +0000 Original-Received: from localhost ([127.0.0.1]:49629 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pToHQ-0007T4-4K for submit@debbugs.gnu.org; Sun, 19 Feb 2023 13:19:20 -0500 Original-Received: from mail-oi1-f181.google.com ([209.85.167.181]:45986) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pToHP-0007Sq-2C for 61532@debbugs.gnu.org; Sun, 19 Feb 2023 13:19:19 -0500 Original-Received: by mail-oi1-f181.google.com with SMTP id o4so1069546oik.12 for <61532@debbugs.gnu.org>; Sun, 19 Feb 2023 10:19:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yuWAN8InVmnlyOLXGgFsx/KoDqP8HGiP2MuO7MBh0p4=; b=MLk1yZ2ELwlqAydg4WWTu78/aC0IOneAXzcoykLOfKaXtPDuJz8+N7yHv05jcu0JCI BrFhjwiDubDMTvwpBfI71MSPIDohu1fEw4oOMSv0ABGhZnN/7f5efTVJnBpNKxYwVazh gyu6H+904YQ+8uvKEze3W3fHks2r+VrknNBSNfxM8IozzhQKNYPvlcAIVeXuPwoGxla8 eF96K0/zEtxujlCiuWFHqciONDOnuvA5Ux0qbUeUH0w1NPpJ+0VmKzr7p/PU/8koOsv1 aEg1/vIZ9lUL8/0ESQTNmVn+HyozltNPeOgdDQcpEkUXmwJ5XCJTvt/Qle1F6P3Kk11v cJvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yuWAN8InVmnlyOLXGgFsx/KoDqP8HGiP2MuO7MBh0p4=; b=xq/VyvMNS0WPvZ7se+6U1okFPWCJeoK2hqJyJSSzizfoaWIJ9aSaKDO8y/AQfOvqzJ TzXASuGuas0yKxgfhVuIpkDdWV4MFP0s7awC+itKo+2pEKSEBCR9WqDERB0Ic8EAgzNc QtD/V1GWShU5H+Y2cRJqLQZ2+JO8E5ksnp6PO0lhcBzLMr14Bo1rVZbi6CNYE0EOzrzJ MpfWPTFrimhrbhxmgDkU5AMTWK7eYegw+fvp3U1gdmAe89Yrwfy1Xalv1aKWQBl8di9K WPoPZwtu8mTTVgpv6LD+hxRwHbhzQxBD8ENlB0mSkZnYCv7vhKTA97lDIc7/IC2L/yRh D2JQ== X-Gm-Message-State: AO0yUKWkdi40CrOBBhNpuKdI9ax6/VLCkKV5r0DCtbdWvNxh1rbTdOVF iSKakYKCCwkoh9Epy8+QXLjKkJCakdTynCR9gUo= X-Google-Smtp-Source: AK7set8pLyHJ8w060wsRuFCP+qUf0gIiiOifRWqmIWOsZ2pGrigZSdrEkf/MxtFt70W7o5uRluw1hbG6K+w+YJMUvtY= X-Received: by 2002:a05:6808:128b:b0:37b:9a3:136f with SMTP id a11-20020a056808128b00b0037b09a3136fmr230891oiw.6.1676830753235; Sun, 19 Feb 2023 10:19:13 -0800 (PST) In-Reply-To: <348D7924-284D-4D14-882E-02C8CAD7A925@thornhill.no> 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:256095 Archived-At: --000000000000652ada05f511953d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Feb 19, 2023 at 4:08 PM Theodor Thornhill wrote= : > > > >bug tracker list. Next time, you can add me to the special X-Debbugs-CC= : > >header] > Pretty sure I did that, but it doesn't matter :) [ I didn't get the message. I went to look in the mbox file off Debbugs and I did find a 'X-Debbugs-Cc' header, but maybe it has to be 'X-Debbugs-CC'?] > I don't think it's a bug, really. Isn't it just the flex style greediness= ? The 'flex' completion style isn't really doing (or at shouldn't be doing) what it does normally. Its purpose in Eglot is only to allow for flex-style fontification of the pattern to happen. Nothing more, and that includes no sorting. That's because, contrary to the normal uses of flex, here it's the server which does all the selection and the filtering for whatever it thinks is a pattern. It turns out that a very common style of filtering among servers is akin to 'flex', so using flex on our side to "paint" the pattern in the completion candidate is usually, though not always, a good bet. If the server happens to use 'prefix' ,then 'flex' will also paint it correctly, in principle. This is of course presuming we guess the filter pattern that the server used, which we're not guaranteed to, but more or less always do by looking for a 'symbol' thing-at-point. Anyway, flex shouldn't be doing any kind of completion sorting for eglot-completion-at-point. So if it is doing that, it's IMO a bug (though perhaps not a serious one, as it wouldn't be a very absurd sorting anyway). > It feels like it tries to match the longest string possible alphabetically? It's > just unintuitive because the json results doesn't match the output, and > debug stepping over was very unhelpful. We could maybe just add > some docs explaining that eglot default, which for many really is an eglot > hard-coding. I hope I explained why it's there. This is what I recall of it, though I may be misremembering. You could help improve the documentation by confirming my recollection hypothesis and adding comments to the code. Anyway, this boils down to a limitation of LSP, that it doesn't report on what kind of matching style it uses for textDocument/completion. At least it used to be a limitation of LSP, maybe someone else has fixed it in the meantime, or added something that we can use. Jo=C3=A3o PS: Added Stefan and Augusto to the discussion since I think they are already familiar with this LSP/Emacs discrepancy regarding completion systems and completion philosophy. --000000000000652ada05f511953d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Feb 19, 2023 at 4:08 PM Theodor Thornhill <theo@thornhill.no> wrote:
>>
> >bug tracker list.=C2=A0 Next time, you can add me to the= special X-Debbugs-CC:
> >header]
> Pretty sure I did that, = but it doesn't matter :)

[ I didn't get the message. I went = to look in the mbox file off Debbugs and I did
find a 'X-Debbugs-Cc&= #39; header, but maybe it has to be 'X-Debbugs-CC'?]

> I = don't think it's a bug, really. Isn't it just the flex style gr= eediness?

The 'flex' completion style isn't really doing= (or at shouldn't be doing)
what it does normally. Its purpose in Eg= lot is only to allow for flex-style
fontification of the pattern to happ= en. Nothing more, and that includes
no sorting.=C2=A0=C2=A0

Tha= t's because, contrary to the normal uses of flex, here it's the
= server which does all the selection and the filtering for whatever
it th= inks is a pattern.=C2=A0 It turns out that a very common style of filtering=
among servers is akin to 'flex', so using flex on our side to &= quot;paint"
the pattern in the completion candidate is usually, tho= ugh not always,
a good bet.=C2=A0 If the server happens to use 'pref= ix' ,then 'flex' will also
paint it correctly, in pri= nciple. This is of course presuming we guess
the filter pattern t= hat the server used, which we're not guaranteed
to, but more = or less always do by looking for a 'symbol' thing-at-point.

Anyway, flex shouldn't be doing any kind of completion sorting f= or
eglot-completion-at-point. So if it is doing that, it's IM= O a bug (though
perhaps not a serious one, as it wouldn't be = a very absurd sorting=C2=A0
anyway).

> It feels = like it tries to match the longest string possible alphabetically? It's=
> just unintuitive because the json results doesn't match the o= utput, and
> debug stepping over was very unhelpful. We could = maybe just add=C2=A0
> some docs explaining that eglot default= , which for=C2=A0many really is an eglot=C2=A0
> hard-coding.<= br>
I hope I explained why it's there.=C2=A0 This is what I recall o= f it, though
I may be misremembering.=C2=A0 You could help improv= e the documentation
by confirming my recollection hypothesis and = adding comments to the
code.

Anyway, thi= s boils down to a limitation of LSP, that it doesn't report on what=C2= =A0
kind of matching style it uses for textDocument/completion.= =C2=A0 At least it
used to be a limitation of LSP, maybe someone else ha= s fixed it in the=C2=A0
meantime, or added something that we can = use.

Jo=C3=A3o

PS: Added Stefan and Augusto= to the discussion since I think they are=C2=A0
already familiar = with this LSP/Emacs discrepancy regarding completion=C2=A0
system= s and completion philosophy.
--000000000000652ada05f511953d--