all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: felician.nemeth@gmail.com, Danny Freeman <danny@dfreeman.email>,
	58790@debbugs.gnu.org, stefankangas@gmail.com, dgutov@yandex.ru,
	Eli Zaretskii <eliz@gnu.org>
Subject: bug#58790: Eglot URI parsing bug when using clojure-lsp server
Date: Wed, 16 Nov 2022 10:21:34 +0000	[thread overview]
Message-ID: <CALDnm52j_8M_akAtNnVPm74EjnLpC9NFSO5X0gRqkddHEifuig@mail.gmail.com> (raw)
In-Reply-To: <87iljf72ua.fsf@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 3120 bytes --]

I don't want to derail de discussion, which seems interesting.

I just want to make a few points:

* Eglot catches `file://` URI references coming from the LSP server
  and converts those -- and only those -- to file names.  It uses
  url-generic-parse for this.  The function eglot--uri-to-path handles
  a few more quirks but is not extraordinarily complex (about 15LOC).

* Eglot converts file names to URIs when it needs to tell the LSP
  about the files it is managing.  Here, too, conversion only happens
  if the PATH argument is not already an URI, in which case nothing happens.

* This logic is fairly simple.  Do you see anything to simplify in it,
Michael?
  Can `url-handlers` simplify the functions `eglot--uri-to-path` and
  `eglot--path-to-uri`?

* I didn't mention that sometimes the "file names" are actually "trampish"
  file names, depending on whether the M-x eglot command was invoked
  in file being visited remotely by the TRAMP facility.

* The only thing that's outstanding in the discussion, as I follow it,
  is that someone suggested that Eglot **warn the user** when the LSP
  server communicates to us (Eglot) a URI scheme that is not known
  by the current Emacs session, and as such `find-file` on it will fail.

* This is (or was) what Danny is asking for: A simple, robust way, for Eglot
  code to ask the current Emacs session if this URI scheme is supported
  downstream, and warn the user preemptively.

* If there's no excellent way to do the above, I think the code shouldn't
  be changed.  The user will eventually be confronted with the failure,
  and once could argue that this moment is when she should be made
  aware of the URI scheme that doesn't have a handler.

João




On Wed, Nov 16, 2022 at 7:53 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Danny Freeman <danny@dfreeman.email> writes:
>
> Hi Danny,
>
> >> Another approach is to simply require url-handlers in eglot.el, when it
> >> comes to handle a URI. It shall do what you want.
> >
> > That is a really interesting idea. I didn't know about the url-handlers
> > package. I think we would want the user to turn on that mode themselves
> > if they were expecting those types of URLs (http, ftp, etc).
>
> You could control this by a user option.
>
> > There are other URI schemes we have seen come through this function that
> > are outside the scope of the url-handlers package. The ones in this
> > particular thread are `jar` and `zipfile` URIs. I've seen other obscure
> > URIs as well that aren't really even standardized and only used by one
> > particular LSP server.
>
> url-handlers.el supports already non-canonical schemes, see
> `url-tramp-protocols'. We could add "jar" and "zipfile" to another user
> option, `url-archive-protocols', and let tramp-archive.el do the job.
>
> The current restriction is, that tramp-archive.el works only on
> GNU/Linux systems. When this is replaced by a native integration of
> libarchive(3) into Emacs, it would work everywhere.
>
> Best regards, Michael.
>


-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 4111 bytes --]

  reply	other threads:[~2022-11-16 10:21 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 21:44 bug#58790: Eglot URI parsing bug when using clojure-lsp server Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-26  6:22 ` Stefan Kangas
2022-10-26 19:50   ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-27 15:09     ` João Távora
2022-10-29  1:22       ` Dmitry Gutov
2022-10-29  2:02         ` João Távora
2022-10-29 14:54           ` Dmitry Gutov
2022-10-29 19:35             ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-31 14:40               ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-02  8:09                 ` João Távora
2022-11-02 13:15                   ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-03 17:10                   ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10  9:49                     ` Eli Zaretskii
2022-11-10 11:00                       ` João Távora
2022-11-10 13:47                         ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 15:38                         ` Eli Zaretskii
2022-11-10 21:45                           ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 21:59                             ` João Távora
2022-11-10 22:22                               ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 22:30                                 ` João Távora
2022-11-10 22:48                                   ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 22:48                                 ` João Távora
2022-11-10 22:57                                   ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-11  7:29                                   ` Eli Zaretskii
2022-11-12 17:03                                     ` Michael Albinus
2022-11-13 21:04                                       ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-15 19:04                                         ` Michael Albinus
2022-11-15 22:28                                           ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-16  7:53                                             ` Michael Albinus
2022-11-16 10:21                                               ` João Távora [this message]
2022-11-16 15:45                                                 ` Michael Albinus
2022-11-16 16:20                                                   ` João Távora
2022-11-16 22:59                                                     ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-02 16:14                                                       ` Michael Albinus
2022-12-07 18:56                                                         ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 13:46                                                           ` Michael Albinus
2022-12-08 19:07                                                             ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-09 16:04                                                               ` Michael Albinus
2022-12-10 17:21                                                                 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-10 17:45                                                                   ` Michael Albinus
2022-11-22 14:30                                                     ` Michael Albinus
2022-11-23 11:55                                                       ` Richard Copley
2022-11-23 12:36                                                         ` João Távora
2022-11-23 12:42                                                           ` Arash Esbati
2022-11-23 12:49                                                             ` Richard Copley
2022-11-23 12:54                                                               ` João Távora
2022-11-23 13:33                                                           ` Eli Zaretskii
2022-11-23 13:44                                                             ` João Távora
2022-11-23 14:03                                                               ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 19:53                                                                 ` João Távora
2022-11-11  8:30                               ` Eli Zaretskii
2022-11-11  9:45                                 ` João Távora
2022-11-11 12:01                                   ` Eli Zaretskii
2022-11-11 14:02                                     ` João Távora
2022-11-11 14:45                                       ` Eli Zaretskii
2022-11-12  9:04                                         ` João Távora
2022-11-11  7:16                             ` Eli Zaretskii
2022-11-01 17:25         ` Juri Linkov
2022-10-29 15:36 ` Felician Nemeth
2022-10-29 17:09   ` João Távora
2022-11-09  0:59 ` bug#58790: Robert Brown

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

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

  git send-email \
    --in-reply-to=CALDnm52j_8M_akAtNnVPm74EjnLpC9NFSO5X0gRqkddHEifuig@mail.gmail.com \
    --to=joaotavora@gmail.com \
    --cc=58790@debbugs.gnu.org \
    --cc=danny@dfreeman.email \
    --cc=dgutov@yandex.ru \
    --cc=eliz@gnu.org \
    --cc=felician.nemeth@gmail.com \
    --cc=michael.albinus@gmx.de \
    --cc=stefankangas@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.