Per #590: Handle keywords in nested maps in configuration #790

fbergroth · 2022-01-10T13:27:01Z

eglot.el (eglot--dump-configuration): Add function
(eglot-signal-didChangeConfiguration): Dump configuration recursively

joaotavora · 2022-01-10T19:20:52Z

In a now-deleted comment you wrote:

@joaotavora I guess this works if elisp lists are used for json maps, and elisp vectors are used for lists. Ugh.

Personally I don't think it's that Ugh, as long as it is cleanly documented somehwere. In Eglot we do use plists for JSON objects and elisp sequences for JSON arrays. We could choose other methods, but I happened to choose this one which I think is the less verbose one (prints better, too, certainly better than the hash-table equivalent).

Does you PR change any of this, or does it mostly fix the bugs and improve the documenation?

fbergroth · 2022-01-10T19:33:40Z

Yeah, I later deleted that comment since I came to realize it wasn't that Ugh.

I pushed some new changes.

The first commit are for the variant which recursively (instead of just at the top level) rewrites ((key . value)) as (:key value), which works, but is confusing and unnecessary, so I reverted it.

I think just keeping the value untouched and referring to json-serialize will make it easier for users. It may create friction since it can break some configurations which is unfortunate.

I've added a helper eglot-show-configuration which dumps the configuration value as json.

Have a look and feel free to change anything.

fbergroth · 2022-01-10T20:03:19Z

Ah, I missed that json-encode is used if json-serialize isn't available, which encodes a bit differently.

(json-serialize '(a 123)) encodes as {"a": 123}, while (json-encode '(a 123)) encodes as ["a", 123].

Hmm, so perhaps the recursive rewrite should be kept?

joaotavora · 2022-01-10T22:05:24Z

(json-serialize '(a 123)) encodes as {"a": 123}, while (json-encode '(a 123)) encodes as ["a", 123].

IIRC the behavior of both these serializers depends very much on additional arguments, in the first case, and special variables in the second case. It should be possible to make these two functions behave equivalently.

fbergroth · 2022-01-11T07:27:34Z

@joaotavora Sorry, I got a bit confused yesterday.

Now I went with a run-time check of the structure as you initially suggested. I think it looks better now.

fbergroth · 2022-01-11T09:55:44Z

@skangas please have a look as well.

The configuration you used here #590 (comment) previously encoded as {'pylsp': {':plugins': {':pydocstyle' ..., and the settings was ignored by the language server. With this PR, the dictionary keys won't have the colons.

fbergroth · 2022-01-11T10:39:48Z

Ah, actually it does work with json-encode but not with json-serialize. Now it should work with both though.

skangas · 2022-01-13T12:51:44Z

Hmm, there are five separate commits here. Could/should any of these commits be squashed? For example, the one that says "fixup!" and the one that documents this in README.md?

joaotavora · 2022-01-13T12:55:24Z

Yeah, if this is a self-contained improvement that it doesn't make sense to split, please to squash as usual. Make history much nicer to read. OTOH if some early commit is laying groundwork for multiple possible other commits, it makes sense to isolate it.

fbergroth · 2022-01-13T12:57:15Z

The commits are a bit sloppy. I didn't want to spend too much time on this before getting some feedback from you. I can clean it up once we agree on the diffs.

Ideally the test should include t nil :json-false and call jsonrpc--json-encode twice. Once to trigger json-serialize, and once with json-serialize uninterned, so json-encode is used.

joaotavora · 2022-01-13T13:26:50Z

The commits are a bit sloppy. I didn't want to spend too much time on this before getting some feedback from you. I can clean it up once we agree on the diffs.

Makes total sense 👍 to me. Will try to find time soon.

skangas · 2022-01-15T14:59:46Z

eglot-tests.el

+  (let ((value (eglot--check-conf '((:k1 (:k2 . [a "b" 1 2.0]) (k3 . v1)))))
+        (expected (string-replace "'" "\"" "{'k1':{'k2':['a','b',1,2.0],'k3':'v1'}}")))
+    (should (equal (json-encode value) expected))
+    (should (equal (json-serialize value) expected))))


Hmm, I'm not sure we should be testing the return value of json-encode and json-serialize here. Should we?

The important test is validating that whatever goes through eglot--check-conf without error should encode to the same value regardless of json-serialize being available or not. I also wrote:

Ideally the test should include t nil :json-false and call jsonrpc--json-encode twice. Once to trigger json-serialize, and once with json-serialize uninterned, so json-encode is used.

... but it's a bit awkward. eglot--check-conf may perhaps better belong in jsonrpc so that internals aren't leaked, but I haven't looked into it.

eglot--check-conf can perhaps be called jsonrpc-safe-encode-transform

I feel like I'm missing something: why should jsonrpc.el have code that relates to how eglot represents it's configuration. Does that really make sense?

BTW, we should probably add an fboundp somewhere, in case json-serialize is not available.

I feel like I'm missing something: why should jsonrpc.el have code that relates to how eglot represents it's configuration. Does that really make sense?

eglot--check-conf is really checking that a particular value is structured in a way so that it encodes the same regardless of json-serialize being available. It's should allow what's common between json-encode and json-serialize (or transform the value such that it becomes that). It could make sense to send any user input through it, but probably it makes more sense to keep it as is.

BTW, we should probably add an fboundp somewhere, in case json-serialize is not available.

There is already (skip-unless (fboundp 'json-serialize)).

Another point why it could belong in jsonrpc, is that the chosen representation is really based on implementation details of jsonrpc, which eglot should not need to know about. What do you think @joaotavora?

skangas · 2022-01-15T14:59:48Z

eglot-tests.el

+(ert-deftest eglot--compare-json-serializers ()
+  (skip-unless (fboundp 'json-serialize))
+  (let ((value (eglot--check-conf '((:k1 (:k2 . [a "b" 1 2.0]) (k3 . v1)))))
+        (expected (string-replace "'" "\"" "{'k1':{'k2':['a','b',1,2.0],'k3':'v1'}}")))


Are there more test cases that are interesting to test? Test coverage could be better: we don't currently test the user-error in eglot--check-conf.

For example, how about in addition to this large example up also create smaller, more focused tests that focus on one of the various branches of eglot--check-conf?

I think stuffing all the cases in a single example is fine (perhaps the existing one can be made to look a bit better), but I can change if you prefer a bunch of smaller ones.

I generally prefer several smaller ones, even if it means some repetition: IME, it is then easier to add new cases, and it is easier to compare the various cases to the various branches.

But yes, it is partly a matter of style, so I don't want to insist too strongly on it. Maybe @joaotavora has an opinion.

skangas · 2022-01-15T15:03:24Z

eglot.el

+   ((listp value)
+    (cl-loop for elem in value
+             unless (consp elem) do
+             (user-error "invalid alist entry `%S' (expected cons)" elem)


Probably better as "Invalid alist entry in configuration: %S"

Shouldn't this be just an error?

Probably better as "Invalid alist entry in configuration: %S"

Sure! Perhaps the string should even be prefixed with eglot: ?

Shouldn't this be just an error?

It'll be signalled when the eglot-workspace-configuration is invalid, such as when the user is using a plist instead of an alist. I think user-error is appropriate, can you elaborate?

How about just using eglot--error? I think then we get the prefix for free.

AFAIK, the only reason for using user-error is to not get a stacktrace when debug-on-error is t. However, I think it would be nice to get a stacktrace in this case.

Makes sense, I wasn't aware of that 👍

skangas · 2022-01-15T15:03:27Z

eglot.el

+             collect (let ((k (car elem)))
+                       (if (keywordp k) k (intern (format ":%s" k))))
+             collect (eglot--check-conf (cdr elem))))
+   (t (user-error "invalid configuration value `%S'" value))))


Probably better as "Invalid configuration value: %S"

Shouldn't this be just an error?

skangas · 2022-01-15T15:04:13Z

README.md

 (go-mode
  . ((eglot-workspace-configuration
-      . ((:gopls . (:usePlaceholders t)))))))
+      . ((:gopls (:usePlaceholders . t)))))))


How about adding the examples from the README as tests?

Sure. In some form, either in the big test or as separate ones.

Sounds good.

skangas · 2022-01-15T15:06:26Z

Could we also have a test for the case you mentioned in #590: '((:a (:b . t)))?

doolio · 2022-09-09T17:05:12Z

@fbergroth was there no need to have this merged in the end?

fbergroth · 2022-09-09T20:48:33Z

I think the changes in eglot.el are useful, but João never got back to this, and I didn't want to pick it up after several months.

joaotavora · 2022-09-09T21:17:33Z

Whoops, sorry indeed that's my bad. The problem is that all the discussion is out of my mental cache now. But on a brief overview, it does look useful and sane.

@doolio can you perhaps state your need/use case for this? What caught your attention in this PR?

doolio · 2022-09-12T06:08:03Z

Thank you both for the quick responses!

I came across this PR when searching through the repository for any mention of eglot-workspace-configuration. I'm trying to configure multiple server settings in a .dir-locals.el file as recommended by the README but where the example is when setting only a single server option. It does though provide an example of setting a single option on more than one server. [Aside: Can one use multiple servers for the same language or is that just silly. I'm wondering if one can use python-lsp-server and pyright at the same time as I believe they provide only some common features but perhaps where they do provide the same they would conflict.] I was struggling to wrap my head around alists and plists. I've been using Emacs for a few years and am trying to learn to programme but have not yet really written any Emacs Lisp.

It seems across various issues, PRs and discussions that users have struggled to set this variable correctly. I find several variations and attempts to do so. I thought this PR was an effort to simplify the setting of this variable for users. Is that correct?

I believe to configure that variable correctly we need to add a plist as the eglot-workspace-configuration alist VALUE value within the .dir-locals.el nested alists if I understood the README correctly. But then this plist can contain nested plists. Please correct me if I'm mistaken.

It seems one can use symbols or keyword symbols (i.e. :symbol) for the eglot-workspace-configuration alist SECTION key but also for the property name (or key) in the plist. It also seems from this Emacs manual page that the plist values for the JSON false and null keywords are by default the keyword symbols :false and :null respectively. But it seems at least such keyword symbol values are not accepted by the python-lsp-server. I've tried variations such as ':false, 'false etc. but to no avail. I've tried using nil for false and it seems to work despite the same Emacs manual page stating nil represents {}, the empty JSON object - but maybe that is why it works? Do you know what symbol we should use to represent the JSON array [] which is another default value of the python-lsp-server? I appreciate the values accepted by the servers are nothing to do with eglot and that they likely differ between servers.

My attempt so far to configure the python-lsp-server as follows works. It enables flake8 as a checker disabling the other checkers which flake8 wraps around and thus avoids duplicate reports in flymake. One must also set the Emacs variable python-flymake-command to ("flake8" "-") as well and obviously have the relevant python packages installed. I've disabled the autopep8 and yapf formatters as I use black via the python-lsp-black plugin for the server.

;;; Directory Local Variables
;;; For more information see (info "(emacs) Directory Variables")

((python-mode
  . ((eglot-workspace-configuration
      . ((:pylsp
          . (:configurationSources ["flake8"]
                                   :plugins (:autopep8 (:enabled nil)
                                                       :flake8 (:enabled t)
                                                       :mccabe (:enabled nil)
                                                       :pycodestyle (:enabled nil)
                                                       :pydocstyle (:enabled nil :convention "pep257")
                                                       :pyflakes (:enabled nil)
                                                       :yapf (:enabled nil)))))))))

Is using nil here wrong? I suspect so but as I stated above none of the different variations I tried worked.

If there is a wiki page under this project I'd be happy to add a .dir-locals.el file for the python-lsp-server to include all the possible settings as given here. It might encourage other users to do the same for other servers? I'd certainly add any for other servers I try.

Thanks for your time and this package.

astoff · 2022-09-12T06:38:43Z

eglot.el

+             unless (consp elem) do
+             (user-error "invalid alist entry `%S' (expected cons)" elem)


Where it the case of a plist handled? It seems to me that a plist would always throw this error.

astoff · 2022-09-12T06:47:03Z

README.md

-      . ((:pyls . (:plugins (:jedi_completion (:include_params t)))))))))
+      . ((:pyls (:plugins (:jedi_completion (:include_params . t)))))))))


Why did you include a dot after :include_params? AFAIU, the only place a cons cell like this can appear in the Elisp -> JSON translation is as an entry of an alist, and this cons appears as an value in a plist.

In fact, (json-encode '(:jedi_completion (:include_params . t))) gives an error and so does json-serialize.

(json-encode '(:jedi_completion (:include_params . t)))

Thanks for this snippet. With this without the erroneous dot, it seems json-serialize encodes the JSON keywords as expected but json-encode only some namely :true and :[].

(json-encode '(:autopep8 (:enabled t))) ; "{\"autopep8\":{\"enabled\":true}}" (json-encode '(:autopep8 (:enabled nil))) ; "{\"autopep8\":{\"enabled\":null}}" (json-encode '(:autopep8 (:enabled :null))) ; "{\"autopep8\":{\"enabled\":\"null\"}}" (json-encode '(:autopep8 (:enabled :false))) ; "{\"autopep8\":{\"enabled\":\"false\"}}" (json-encode '(:autopep8 (:enabled []))) ; "{\"autopep8\":{\"enabled\":[]}" (json-serialize '(:autopep8 (:enabled t))) ; "{\"autopep8\":{\"enabled\":true}}" (json-serialize '(:autopep8 (:enabled nil))) ; "{\"autopep8\":{\"enabled\":{}}}" (json-serialize '(:autopep8 (:enabled :null))) ; "{\"autopep8\":{\"enabled\":null}}" (json-serialize '(:autopep8 (:enabled :false))) ; "{\"autopep8\":{\"enabled\":false}}" (json-serialize '(:autopep8 (:enabled []))) ; "{\"autopep8\":{\"enabled\":[]}"

I believe jsonrpc uses json-encode as an alias to json-serialize so I don't quite understand why :null and :false were not acceptable in my above 'dir-locals.el example.

It's because jsonrpc--json-encode modifies what Elisp values these functions use for JSON null and false.

To debug your server configuration, you should use jsonrpc--json-encode only.

@doolio in case you didn't know this, the behaviour of json-encode is affected by multiple dynamic variable bindings.

I think @astoff is also trying to tell you this.

jsonrpc.el sets these variables. I don't know if you're taking this into account in your tests, or what these tests are supposed to mean. Eglot does not use json-serialize or json-encode directly, rather jsonrpc.el.

It's jsonrpc.el which sometimes uses one and sometimes uses the other.

:[] is not a keyword, it gets read as the keyword : followed by the empty vector.

:[] is not a keyword, it gets read as the keyword : followed by the empty vector.

Yes, I corrected the above tables. Thanks.

@joaotavora any thoughts on this comment?

This PR is about how the keys of the JSON objects are handled, so this comment seems a bit unrelated to me. But it is perhaps a bit of a problem that the values in the JSON object have to be provided in the way jsonrcp--json-serialize expects them, because that function is convenient for the Lisp programmer but not necessarily the most user-friendly.

For the end user, it would maybe be more friendly to allow the following translations:

JSON false <-> :false JSON true <-> t or :true JSON null <-> nil or :null JSON {} <-> I don't know, maybe :{}?

This PR is about how the keys of the JSON objects are handled, so this comment seems a bit unrelated to me.

True, I could open a new issue under jsonrpc.el if João feels it is more appropriate. I added it here as the discussion was fresh in people's minds and so seemed appropriate.

The translations I suggest above I based on this Emacs manual page.

astoff · 2022-09-12T11:50:49Z

I thought this PR was an effort to simplify the setting of this variable for users. Is that correct?

@doolio While this PR fixes some corner cases, I don't think it simplifies the overall process for the user — or at least it will not change anything for your attempted configuration. But what do you think of this suggestion?

Also tweak eglot-show-workspace-configuration a bit. * README.md (Workspace configuration): Rework. * eglot.el (eglot-show-workspace-configuration): Rework. (eglot--workspace-configuration-plist): New helper.

astoff · 2022-09-17T08:11:22Z

The top-level structure is an alist. And the lower structures can be anything that json-serialize can grok, though keyword-value plists are recommended.

Right, and this special requirement on the top level can only add to confusion, right?

I added some specific comments to the new README directly to in the commit.

Here's one a more "global" comment: The entire "Format" section should not be needed. Instead, Eglot should be such that the following is all you need to say:

eglot-workspace-configuration can have any value that json-serialize understands. Typically, it will be a nested structure of plists or alists, which are then sent to the server as a nested JSON object. The JSON true, false and null values are represented by the Lisp values t and :json-false and nil respectively. JSON arrays are represented by Lisp vectors.

* README.md (way): Adjust. * eglot.el (json): Don't require needlessly. (eglot-show-workspace-configuration): Don't depend on json-mode.

joaotavora · 2022-09-17T09:37:32Z

I think you got a bug in the first example in the readme. For me, it serializes to {":pyls": { ...

That's if you call json-serialize on the whole object directly. But why would you do that? You let Eglot serialize it. You can simulate this with M-x eglot-show-configuration.

Yes, but it can get tricky if you want to use the same configuration in emacs compiled without libjansson, where json-serialize is not available. Then "anything that json-serialize can grok" can serialize differently.

This is why plists are recommended. As far as I understand those pitfalls are only when you put alists in the sub-section structure.

fbergroth · 2022-09-17T09:50:40Z

That's if you call json-serialize on the whole object directly. But why would you do that? You let Eglot serialize it. You can simulate this with M-x eglot-show-configuration.

Sorry, my mistake, I had some parts of this PR evaled.

joaotavora · 2022-09-17T10:02:37Z

Here's one a more "global" comment: The entire "Format" section should not be needed. Instead, Eglot should be such that the following is all you need to say:
eglot-workspace-configuration can have any value that json-serialize understands.

If we allow eglot-workspace-configuration to be a plist of anything -- as you suggest in #1033 -- then yes, that statement is mostly true but still has the caveats pointed out by @fbergroth. However:

I'm not convinced the complexity is worth it
Allow eglot-workspace-configuration to be a plist #1033 isn't finished yet (it doesn't handle the workspace/configuration request).

joaotavora · 2022-09-17T10:04:32Z

@doolio

For what it is worth I have created a .dir-locals.el for all the available settings for the pylsp server. It already follows the form in your example. In doing so I found some discrepancies in the pylsp schema.json and have submitted a PR to correct them. Once approved I can add this .dir-locals.el here to the 'Show and Tell` section of the Discussions page. It may encourage others to do the same for other servers.

Yes that would be welcome.

Yes, pylsp is now favoured over pyls which I believe is no longer actively maintained. It would just be a matter of changing pyls to pylsp everywhere in your example.

Really? Do they accept the same configuration settings exactly?

astoff · 2022-09-17T11:00:33Z

This is why plists are recommended. As far as I understand those pitfalls are only when you put alists in the sub-section structure.

By the way, there's no good reason to use keyword keys in those plists, and if we don't then we protect the user from even knowing about those pitfalls. So, concretely, say this in the simple example:

((python-mode
  . ((eglot-workspace-configuration
      .
      ;; the value in the format described above starts here
      ((pyls . (plugins (jedi_completion (include_params t
                                          fuzzy t)
                         pylint (enabled :json-false)))))
      ;; and ends here
      ))))

I'm not convinced the complexity is worth it

I don't understand what you mean here: what is more complex?

#1033 isn't finished yet (it doesn't handle the workspace/configuration request).

Do you agree workspace/configuration support is broken, or at least not completely conformant to the spec? If so, then we can either merge #1033 now and fix everything later, or fix first workspace/configuration first and then I'll adapt my PR.

Really? Do they accept the same configuration settings exactly?

Yes, or at least for the most part. Just need to change the top level key from pyls to pylsp.

doolio · 2022-09-17T11:17:06Z

Really? Do they accept the same configuration settings exactly?

Yes, from what I can tell you simply need to change the top level key to pylsp from pyls. Saying that, if you compare this (from pylsp) to this (from pyls) it seems more settings have since been added to pylsp but that is perhaps unsurprising if pyls is no longer being actively developed.

Suggested-by: Augusto Stoffel <[email protected]> * NEWS.md: Mention change. * README.md (eglot-workspace-configuration): Update yet again. * eglot.el (eglot--workspace-configuration-plist): Noop if already a plist. (eglot-handle-request workspace/configuration): Use eglot--workspace-configuration-plist.

Suggested-by: Augusto Stoffel <[email protected]> * NEWS.md: Mention change. * README.md (eglot-workspace-configuration): Update yet again. Update examples to use pylsp. * eglot.el (eglot--workspace-configuration-plist): Noop if already a plist. (eglot-handle-request workspace/configuration): Use eglot--workspace-configuration-plist. (eglot-workspace-configuration): Document variable.

joaotavora · 2022-09-18T10:01:33Z

@fbergroth #1033 has been merged (sort of), meaning that eglot-workspace-configuration can now be a plist fully. The existing function eglot--workspace-configuraiton-plist (which could be renamed) would be a good place to put the existing "sanitization" logic. I think it's decently useful to have this sanitizer. I'll keep the PR open in case you want to work on that. Otherwise, I thank you for the work so far and you may close it (again).

fbergroth · 2022-09-18T11:22:12Z

Thanks. Perhaps it's more useful to just do normalization rather than validation (to handle dotted configuration section lookups). I'll close this again for now.

…pace configurations Also see joaotavora/eglot#790, joaotavora/eglot#1033.

…out workspace configuration * README.md (way): Adjust. * eglot.el (json): Don't require needlessly. (eglot-show-workspace-configuration): Don't depend on json-mode.

… Allow eglot-workspace-configuration to be a plist Suggested-by: Augusto Stoffel <[email protected]> * NEWS.md: Mention change. * README.md (eglot-workspace-configuration): Update yet again. Update examples to use pylsp. * eglot.el (eglot--workspace-configuration-plist): Noop if already a plist. (eglot-handle-request workspace/configuration): Use eglot--workspace-configuration-plist. (eglot-workspace-configuration): Document variable.

…pace configurations Also see joaotavora/eglot#790, joaotavora/eglot#1033.

…out workspace configuration * README.md (way): Adjust. * eglot.el (json): Don't require needlessly. (eglot-show-workspace-configuration): Don't depend on json-mode.

… Allow eglot-workspace-configuration to be a plist Suggested-by: Augusto Stoffel <[email protected]> * NEWS.md: Mention change. * README.md (eglot-workspace-configuration): Update yet again. Update examples to use pylsp. * eglot.el (eglot--workspace-configuration-plist): Noop if already a plist. (eglot-handle-request workspace/configuration): Use eglot--workspace-configuration-plist. (eglot-workspace-configuration): Document variable.

Also see #790, #1033. #590: joaotavora/eglot#590 #790: joaotavora/eglot#790 #1033: joaotavora/eglot#1033

* README.md (way): Adjust. * eglot.el (json): Don't require needlessly. (eglot-show-workspace-configuration): Don't depend on json-mode. #790: joaotavora/eglot#790 #590: joaotavora/eglot#590

Suggested-by: Augusto Stoffel <[email protected]> * NEWS.md: Mention change. * README.md (eglot-workspace-configuration): Update yet again. Update examples to use pylsp. * eglot.el (eglot--workspace-configuration-plist): Noop if already a plist. (eglot-handle-request workspace/configuration): Use eglot--workspace-configuration-plist. (eglot-workspace-configuration): Document variable. #590: joaotavora/eglot#590 #790: joaotavora/eglot#790 #1033: joaotavora/eglot#1033

Also see joaotavora/eglot#790, joaotavora/eglot#1033. GitHub-reference: per joaotavora/eglot#590

* README.md (way): Adjust. * eglot.el (json): Don't require needlessly. (eglot-show-workspace-configuration): Don't depend on json-mode. GitHub-reference: per joaotavora/eglot#790 GitHub-reference: per joaotavora/eglot#590

Suggested-by: Augusto Stoffel <[email protected]> * NEWS.md: Mention change. * README.md (eglot-workspace-configuration): Update yet again. Update examples to use pylsp. * eglot.el (eglot--workspace-configuration-plist): Noop if already a plist. (eglot-handle-request workspace/configuration): Use eglot--workspace-configuration-plist. (eglot-workspace-configuration): Document variable. GitHub-reference: per joaotavora/eglot#590 GitHub-reference: per joaotavora/eglot#790 GitHub-reference: per joaotavora/eglot#1033

Also see joaotavora/eglot#790, joaotavora/eglot#1033. GitHub-reference: per joaotavora/eglot#590

* README.md (way): Adjust. * eglot.el (json): Don't require needlessly. (eglot-show-workspace-configuration): Don't depend on json-mode. GitHub-reference: per joaotavora/eglot#790 GitHub-reference: per joaotavora/eglot#590

Suggested-by: Augusto Stoffel <[email protected]> * NEWS.md: Mention change. * README.md (eglot-workspace-configuration): Update yet again. Update examples to use pylsp. * eglot.el (eglot--workspace-configuration-plist): Noop if already a plist. (eglot-handle-request workspace/configuration): Use eglot--workspace-configuration-plist. (eglot-workspace-configuration): Document variable. GitHub-reference: per joaotavora/eglot#590 GitHub-reference: per joaotavora/eglot#790 GitHub-reference: per joaotavora/eglot#1033

fbergroth marked this pull request as draft January 10, 2022 13:31

fbergroth marked this pull request as ready for review January 10, 2022 15:28

fbergroth force-pushed the configuration branch from f1d013b to dff3b0a Compare January 10, 2022 19:21

fbergroth force-pushed the configuration branch 2 times, most recently from 7bf7daf to 1a29ba2 Compare January 11, 2022 07:22

skangas reviewed Jan 15, 2022

View reviewed changes

skangas linked an issue Jan 15, 2022 that may be closed by this pull request

workspace configuration options not working with pyls #590

Closed

fbergroth closed this Mar 15, 2022

fbergroth mentioned this pull request Sep 11, 2022

Allow eglot-workspace-configuration to be a plist #1033

Closed

astoff reviewed Sep 12, 2022

View reviewed changes

joaotavora added a commit that referenced this pull request Sep 17, 2022

Per #790, #590: Adjust last commit about workspace configuration

a67284b

* README.md (way): Adjust. * eglot.el (json): Don't require needlessly. (eglot-show-workspace-configuration): Don't depend on json-mode.

joaotavora mentioned this pull request Sep 17, 2022

workspace configuration options not working with pyls #590

Closed

fbergroth closed this Sep 18, 2022

bhankas pushed a commit to bhankas/emacs that referenced this pull request Sep 18, 2022

Per joaotavora/eglot#590: Add eglot-show-configuration to debug works…

d09b972

…pace configurations Also see joaotavora/eglot#790, joaotavora/eglot#1033.

bhankas pushed a commit to bhankas/emacs that referenced this pull request Sep 19, 2022

Per joaotavora/eglot#590: Add eglot-show-configuration to debug works…

282a63b

…pace configurations Also see joaotavora/eglot#790, joaotavora/eglot#1033.

bhankas pushed a commit to bhankas/emacs that referenced this pull request Sep 19, 2022

Per #590: Add eglot-show-configuration to debug workspace configurations

66ce68b

Also see #790, #1033. #590: joaotavora/eglot#590 #790: joaotavora/eglot#790 #1033: joaotavora/eglot#1033

jollaitbot pushed a commit to sailfishos-mirror/emacs that referenced this pull request Oct 12, 2022

Add eglot-show-configuration to debug workspace configurations

d49af3b

Also see joaotavora/eglot#790, joaotavora/eglot#1033. GitHub-reference: per joaotavora/eglot#590

jollaitbot pushed a commit to sailfishos-mirror/emacs that referenced this pull request Oct 20, 2022

Add eglot-show-configuration to debug workspace configurations

51ae66b

Also see joaotavora/eglot#790, joaotavora/eglot#1033. GitHub-reference: per joaotavora/eglot#590

		unless (consp elem) do
		(user-error "invalid alist entry `%S' (expected cons)" elem)

		. ((:pyls . (:plugins (:jedi_completion (:include_params t)))))))))
		. ((:pyls (:plugins (:jedi_completion (:include_params . t)))))))))

Per #590: Handle keywords in nested maps in configuration #790

Per #590: Handle keywords in nested maps in configuration #790

Conversation

fbergroth commented Jan 10, 2022

joaotavora commented Jan 10, 2022

fbergroth commented Jan 10, 2022

fbergroth commented Jan 10, 2022

joaotavora commented Jan 10, 2022

fbergroth commented Jan 11, 2022

fbergroth commented Jan 11, 2022

fbergroth commented Jan 11, 2022

skangas commented Jan 13, 2022

joaotavora commented Jan 13, 2022

fbergroth commented Jan 13, 2022

joaotavora commented Jan 13, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

skangas commented Jan 15, 2022

doolio commented Sep 9, 2022

fbergroth commented Sep 9, 2022

joaotavora commented Sep 9, 2022

doolio commented Sep 12, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

astoff commented Sep 12, 2022 • edited Loading

astoff commented Sep 17, 2022

joaotavora commented Sep 17, 2022

fbergroth commented Sep 17, 2022

joaotavora commented Sep 17, 2022

joaotavora commented Sep 17, 2022

astoff commented Sep 17, 2022

doolio commented Sep 17, 2022

joaotavora commented Sep 18, 2022

fbergroth commented Sep 18, 2022

astoff commented Sep 12, 2022 •

edited

Loading