From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.bugs Subject: bug#61532: 30.0.50; [PATCH]: Make completions without sortText fall to back of the list Date: Tue, 21 Feb 2023 09:24:42 +0100 Message-ID: <87y1orfmt1.fsf@gmail.com> References: <87ttzn6kxb.fsf@thornhill.no> <875yby62j9.fsf@thornhill.no> <348D7924-284D-4D14-882E-02C8CAD7A925@thornhill.no> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13116"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 61532@debbugs.gnu.org, Theodor Thornhill , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 21 09:25:47 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 1pUNy7-0003HI-EQ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Feb 2023 09:25:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUNxe-00065C-8N; Tue, 21 Feb 2023 03:25:20 -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 1pUNxP-00064V-56 for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 03:25:04 -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 1pUNxO-00079T-Na for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 03:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pUNxO-00084S-Cv for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 03:25:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Augusto Stoffel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Feb 2023 08:25: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.167696789230991 (code B ref 61532); Tue, 21 Feb 2023 08:25:02 +0000 Original-Received: (at 61532) by debbugs.gnu.org; 21 Feb 2023 08:24:52 +0000 Original-Received: from localhost ([127.0.0.1]:54460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUNxE-00083m-IW for submit@debbugs.gnu.org; Tue, 21 Feb 2023 03:24:52 -0500 Original-Received: from mail-ed1-f53.google.com ([209.85.208.53]:39922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUNxC-00083a-Od for 61532@debbugs.gnu.org; Tue, 21 Feb 2023 03:24:51 -0500 Original-Received: by mail-ed1-f53.google.com with SMTP id f13so13210182edz.6 for <61532@debbugs.gnu.org>; Tue, 21 Feb 2023 00:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=l9hJ8f0EwqXL4gkADWuvLujL7JKAu5OuFT0ARM6O/AM=; b=CIN/xVpOOxAaZgBVz54NIHOA+/kDq0S2RSAWIBXNfAlAgFeEKbAPvb9n+SxPhVt/Ge 1+BLS/PFpcYjyW+c0HwjgnQYoKtuCi5zwYSP62YAJCQVDHaU+3gWmRjL4Q2V5q0wnctB Wqp4GlX5Skw8/lWpGvRyprAdAWv2ncVtsqWv2uICtACYKU/P1sDM5FoYRS9G1V+P7WFW TcMZQSCpn+3zpgLIA3Qxa2hFpFgq2MqcCKkxukMjaTw8vmjiMhKNxIjtSvRyGyDqM7aY J46MYQlSOfahMSY15svEqpMfBMe+ulJHKJqkYwbxYRCVoNVeLzrCoWjuqmjYI8thKWdx vCLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=l9hJ8f0EwqXL4gkADWuvLujL7JKAu5OuFT0ARM6O/AM=; b=58VC0oMJBr+AMkUO+auRGBSM6wXQN93sodlhzR4exlz7sQ6RfiFKsAAAXAnX6nubhZ WE8DaQXmchgEFc690AtS3VNBpTugJd6gdCaSmG08Kb0WJ9kfodzsSoQfmnjstblYvZw0 ZF+dV/XFegqrDPWkvVEQnFhoYoSHGJIxarL3FN8QqTkDUA93veikc23aYwyDohGByhuZ exYHM67/YxTC8mUAwJfXepg55/WVGD58d6m/DetxiT8OwIj0fS5BvYC12YbT3BJJbXUg /N2ybSwVnCBTWGo1Vbd84b+K7yvSqoKfZad3NAuC5E/iM7r/jJlIXz7XERZj5aN5cvYM 1Wlg== X-Gm-Message-State: AO0yUKWHobu9AAhMuh/bghop2X9/73ZaSTy75EV/Ig1ip3KYdv/F5BE7 jDsGyjbRwXkN70AUkqQudvejFQ434Gs= X-Google-Smtp-Source: AK7set9M0O0ZfZGqjua2cWKE2wAmO48+uTqvJwSN/lQxue+LS28OY48lKMMnJrazmIf2YDTc9cttkw== X-Received: by 2002:a17:906:255b:b0:8af:3fcc:2b05 with SMTP id j27-20020a170906255b00b008af3fcc2b05mr11042938ejb.12.1676967884336; Tue, 21 Feb 2023 00:24:44 -0800 (PST) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::6fd0]) by smtp.gmail.com with ESMTPSA id u16-20020a1709063b9000b008d7a8083dffsm1835253ejf.222.2023.02.21.00.24.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Feb 2023 00:24:43 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Sun, 19 Feb 2023 17:56:06 -0500") 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:256236 Archived-At: On Sun, 19 Feb 2023 at 17:56, Stefan Monnier wrote: >> 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. > > It's not just "matching style". It's that it's designed under the > premise that all the control is on the LSP server side, and the client > (editor) side just provides a "dumb UI". This not quite true, actually. I once proposed a mechanism for the server to request the editor to "act dumb", but the idea didn't stick. Also, I gather from the discussion that VS Code does its own sorting and filterting too. https://github.com/microsoft/language-server-protocol/issues/898 > A better API is probably harder to design (e.g. you need to define what > is a "matching style", for one), admittedly. I think if the server returns all possible candidates with no filtering, then Emacs would be happy, right? Apparently some servers do that, as claimed in the above discussion. Of course there is one big issue with this approach, namely the response can be quite big and slow down both ends of the communication channel.