Add simple support for workspaceFolders

[nemethf]

Fixes #890.

I haven't tested the workspace/workspaceFolders request, because I don't know any servers that sends this. But this part of the PR is quite trivial.

---

Clients can support workspaceFolders since LSP 3.6. rootUri and
rootPath are deprecated. Dynamic changes in folders are not
supported, i.e., this patch does not implement
workspace/didChangeWorkspaceFolders.

• eglot.el (eglot-client-capabilities): Add capability
  `workspaceFolders'.
  (eglot-workspace-folders): New cl-defgeneric.
  (eglot--connect): Add workspaceFolders to initializeParams.
  (eglot-handle-request workspace/workspaceFolders): New cl-defmethod.

[joaotavora]

Read it, looks rather perfect. :) Two questions

1. Man that uniquify thing is tricky indeed. Doesn't this make some "garbage" dired buffers behind the user's back? Even in the common case, it opens the main root right? Shouldn't we clean up? I know it's more boring code, but still...

2. If rootURI and rootPath are deprecated, is it ok to provide both wsfolders and these other two at the same time?

[joaotavora]

Also aren't there some server capability checks in order?

[nemethf]

1. Man that uniquify thing is tricky indeed. Doesn't this make some "garbage" dired buffers behind the user's back? Even in the common case, it opens the main root right? Shouldn't we clean up? I know it's more boring code, but still...

Yes, garbage buffers are left behind. Should I make an attempt to clean them? Personally I think it's not a problem.

2. If rootURI and rootPath are deprecated, is it ok to provide both wsfolders and these other two at the same time?

I think so. The client doesn't know whether the server supports workspace-folders before receiving the server-capabilities.

Also aren't there some server capability checks in order?

Can you elaborate?

[joaotavora]

Yes, garbage buffers are left behind. Should I make an attempt to clean them?

I don't think the normal user would like a surprising dired buffer to appear as a result of M-x eglot. Thinking about this, I would err on the side of simplicity, don't care about uniquified folder names, and just use file-name-base for getting the name.
Else, you must use find-buffer-visiting to check which ones are already open beforehand, then use cl-intersection to find the ones you have to kill in an unwind-protect unwind block.

I think my simplistic suggestion where in some (presumably edge) cases we get duplicate names is much better. The server itself can always disambiguate them with the URI, right? Does the spec suggest otherwise?

I think so. The client doesn't know whether the server supports workspace-folders before receiving the server-capabilities.

Also aren't there some server capability checks in order?
Can you elaborate?

No need. You just answered in the previous line :-) There are no server caps to check because we don't have the list yet. So that part is fine.

[nemethf]

I would err on the side of simplicity, don't care about uniquified folder names, and just use file-name-base for getting the name.

I'm OK with file-name-base, but how about abbreviate-file-name instead?

(cl-defgeneric eglot-workspace-folders (server)
  "Return workspaceFolders for SERVER."
  (let ((project (eglot--project server)))
    (vconcat
     (mapcar (lambda (dir)
               (list :uri (eglot--path-to-uri dir)
                     :name (abbreviate-file-name dir)))
             `(,(project-root project) ,@(project-external-roots project))))))

I think my simplistic suggestion where in some (presumably edge) cases we get duplicate names is much better. The server itself can always disambiguate them with the URI, right? Does the spec suggest otherwise?

The specification mentions just this: "The name of the workspace folder. Used to refer to this workspace folder in the user interface." So I think the servers do not care; in some notifications they might refer to a workspace by its name, and the user should recognize the name.

[joaotavora]

I don't know what abbreviate-file-name does, but it sure sounds promising, so yes, go ahead :-)

[joaotavora]

Can you add this to the NEWS.md file too. I think it's reasonably relevant. Sorry I forgot to mention that :-)

[nemethf]

Can you add this to the NEWS.md file too.
done