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#58790: Eglot URI parsing bug when using clojure-lsp server Date: Wed, 23 Nov 2022 12:36:37 +0000 Message-ID: References: <9bb290c8-f000-31d8-265d-b5441c33eb38@dfreeman.email> <4d50b820-7053-75eb-5b11-d3d36a02b013@dfreeman.email> <87v8nxsrq6.fsf@gmail.com> <87cza40xgs.fsf@dfreeman.email> <83edubrvf0.fsf@gnu.org> <87cz9v9irh.fsf@gmail.com> <83o7terf9a.fsf@gnu.org> <87k042tqze.fsf@dfreeman.email> <87fseqtpiu.fsf@dfreeman.email> <875yfm8lzf.fsf@gmail.com> <83wn82osoo.fsf@gnu.org> <871qq8xfzr.fsf@gmx.de> <87mt8uwo2q.fsf@dfreeman.email> <87zgcs6nvb.fsf@gmx.de> <87r0y3luad.fsf@dfreeman.email> <87iljf72ua.fsf@gmx.de> <87a64qykcf.fsf@gmx.de> <8735ab12pr.fsf@gmx.de> <720bcf72-e944-4978-982f-4b6fa8b31e5c@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000039e59105ee228682" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1460"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Felician Nemeth , Danny Freeman , 58790@debbugs.gnu.org, Michael Albinus , Stefan Kangas , Dmitry Gutov , Eli Zaretskii To: Richard Copley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 23 13:36:20 2022 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 1oxozD-0000DD-Cj for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Nov 2022 13:36:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxoz3-0003aS-9S; Wed, 23 Nov 2022 07:36:10 -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 1oxoyy-0003a2-5S for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 07:36: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 1oxoyw-0006VA-PA for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 07:36:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oxoyw-00040Q-2T for bug-gnu-emacs@gnu.org; Wed, 23 Nov 2022 07:36: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: Wed, 23 Nov 2022 12:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58790 X-GNU-PR-Package: emacs Original-Received: via spool by 58790-submit@debbugs.gnu.org id=B58790.166920694015365 (code B ref 58790); Wed, 23 Nov 2022 12:36:02 +0000 Original-Received: (at 58790) by debbugs.gnu.org; 23 Nov 2022 12:35:40 +0000 Original-Received: from localhost ([127.0.0.1]:54066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxoya-0003zk-7i for submit@debbugs.gnu.org; Wed, 23 Nov 2022 07:35:40 -0500 Original-Received: from mail-oa1-f53.google.com ([209.85.160.53]:38458) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxoyX-0003zW-KS for 58790@debbugs.gnu.org; Wed, 23 Nov 2022 07:35:38 -0500 Original-Received: by mail-oa1-f53.google.com with SMTP id 586e51a60fabf-1322d768ba7so20641903fac.5 for <58790@debbugs.gnu.org>; Wed, 23 Nov 2022 04:35:37 -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=zm6MkHn4jX0Kcq4LA3F/phom6Rm8+lWjn9VcsEjFOxY=; b=f0R2/kRCBBBsldNvKrPYncirvp1GSYCGH+05zo1IFYcdE234pWBtgfWuD+CFgtMggc efcvCEUN3bfhBkq9ACXrZZ54KkczcYoPqF1FgjoLVP6tmmeOGraaAVxuMgD/HJwsmkAH AidVTkyIj8ZW2ruJs4uYVRrnQ0WTlAskBokD0be8Vwif9Iw7yLPJ8blA0PMGDIdOqdJJ 6GiKpl4YBY8TeffZyPY4PA0Cqfq7ImS3tYecrUAQcTz8eqMq+K10Fqc4EsYdyZPeq64q B2Sm1uiz6VVhW8b0XroLyJcRZCPFHAMdprah/Z2fKxzC2f276SxOdXKLCiwJwKL77IbV QzPw== 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=zm6MkHn4jX0Kcq4LA3F/phom6Rm8+lWjn9VcsEjFOxY=; b=PqI+uMT6BQE7uGEkwTPE/QwcXABkfy7RLq7D8xO/oPv4ta1xqfzGQRAY+i8R8T/sna zBlnCKZq9FbKg/OKe84W7hceo++xSjujfEQzMAu84TTgiIRC/uZaVxxctbg6KAD6LKUG QaejATsGf1Qtao1dJPONXchQ5rfJ6IjfI587PPQArNQ1Zfae+3U9TaUYEGpa97RVnIhb YyqSG3sREjDcHplmg1gt+MShatt1yjBseA9F57CJSthTOcDS42SMVb6Wao8VNfNZVbvI CGx/RPnW4F8DTnVgs5LXGOXz2PduagsFJLzcCj0Vdde2PIrstn2cek+KUWPX6hl57aZ6 RTpw== X-Gm-Message-State: ANoB5pnAAzYVNDsWwJOZMWw6YRErB+OwyqqQIJF1v46kDOqqmNVMgMuH tAYWpKDZp6D42G1DZOtdSrZupToP30Gt70gfnU4= X-Google-Smtp-Source: AA0mqf6VkL2HWOKC063ykacCe8NDOU2fZ3/edildJKszxJulQ9fkmBFt3rAaBt80/N1KknAfLVM4IfFzGn7lYx50lSU= X-Received: by 2002:a05:6871:4590:b0:132:a103:ae22 with SMTP id nl16-20020a056871459000b00132a103ae22mr15758602oab.215.1669206931791; Wed, 23 Nov 2022 04:35:31 -0800 (PST) In-Reply-To: <720bcf72-e944-4978-982f-4b6fa8b31e5c@gmail.com> 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:248732 Archived-At: --00000000000039e59105ee228682 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes,I think I follow. To be clear I think the problem is somewhere in (defun eglot--path-to-uri (path) "URIfy PATH." (let ((truepath (file-truename path))) (if (url-type (url-generic-parse-url truepath)) ;; Path is already a URI, so forward it to the LSP server ;; untouched. The server should be able to handle it, since ;; it provided this URI to clients in the first place. truepath ...) So either url-generic-parse-url and url-type is fixed in url-parse.el, or we must add some Windows-specific guards in eglot.el. Or likely both, since url-parse.el is not a :core ELPA package. Richard/Danny, can you perhaps come up with some patch? Jo=C3=A3o On Wed, Nov 23, 2022 at 11:55 AM Richard Copley wrote: > On 22/11/2022 14:30, Michael Albinus wrote: > > Jo=C3=A3o T=C3=A1vora writes: > > > > Hi Jo=C3=A3o, > > > >> Both seem to be OK, although I'm not sure that it is the right > >> approach in eglot--path-to-uri just to concat "file://" and the > >> file-local-name part of a remote file name. > >> > >> Can you describe a case where this would be problematic? Remember > >> that, from the point of view of the server, the file is always local. > >> That's regardless of whether eglot invoked the server remotely or > >> locally. > > > > Got it. > > > > Best regards, Michael. > > Hi All, > > For file names with a Windows drive letter and forward slashes (as > emitted by CMAKE_EXPORT_COMPILE_COMMANDS), the drive letter is > misinterpreted as a URL type, leading to repeated errors, > "clangd only supports 'file' URI scheme for workspace files". > > > (let ((path "c:/projects/awesome-project/source/main.cpp")) > (message "type %s, url %s" > (url-type (url-generic-parse-url path)) > (eglot--path-to-uri path))) > > ;; =3D> "type c, url c:/projects/awesome-project/source/main.cpp" > > --=20 Jo=C3=A3o T=C3=A1vora --00000000000039e59105ee228682 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Yes,I think I follow.=C2=A0 To be clea= r I think the problem is somewhere in

(defun = eglot--path-to-uri (path)
=C2=A0 "URIfy PATH."
=C2=A0 (let = ((truepath (file-truename path)))
=C2=A0 =C2=A0 (if (url-type (url-gener= ic-parse-url truepath))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Path is already a= URI, so forward it to the LSP server
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; unt= ouched.=C2=A0 The server should be able to handle it, since
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 ;; it provided this URI to clients in the first place.=C2=A0 =C2=A0 =C2=A0 =C2=A0 truepath
=C2=A0 =C2=A0 =C2=A0 ...)

So either url-generic-parse-url and url-type is fixed in u= rl-parse.el, or
we must add some Windows-specific guards in = eglot.el.=C2=A0 Or likely
both, since url-parse.el is not a :core= ELPA package.

Richard/Danny, can you perhaps come= up with some patch?

Jo=C3=A3o

=
On Wed, No= v 23, 2022 at 11:55 AM Richard Copley <rcopley@gmail.com> wrote:
On 22/11/2022 14:30, Michael Albinus= wrote:
> Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> writes:
>
> Hi Jo=C3=A3o,
>
>>=C2=A0 =C2=A0 =C2=A0 Both seem to be OK, although I'm not sure = that it is the right
>>=C2=A0 =C2=A0 =C2=A0 approach in eglot--path-to-uri just to concat = "file://" and the
>>=C2=A0 =C2=A0 =C2=A0 file-local-name part of a remote file name. >>
>> Can you describe a case where this would be problematic? Remember<= br> >> that, from the point of view of the server, the file is always loc= al.
>> That's regardless of whether eglot invoked the server remotely= or
>> locally.
>
> Got it.
>
> Best regards, Michael.

Hi All,

For file names with a Windows drive letter and forward slashes (as
emitted by CMAKE_EXPORT_COMPILE_COMMANDS), the drive letter is
misinterpreted as a URL type, leading to repeated errors,
=C2=A0 =C2=A0"clangd only supports 'file' URI scheme for works= pace files".


(let ((path "c:/projects/awesome-project/source/main.cpp"))
=C2=A0 =C2=A0(message "type %s, url %s"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (url-type (url-generic-parse-url = path))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (eglot--path-to-uri path)))

;; =3D> "type c, url c:/projects/awesome-project/source/main.cpp&qu= ot;



--
Jo=C3=A3o = T=C3=A1vora
--00000000000039e59105ee228682--