Replies: 5 comments 5 replies
-
You "feel" that, but as the manual says, it "makes little sense". Are you hanging on to that residue of sense that you think it makes? Anyway, there's a section devoted to this already, I don't think we need any more? Besides, Eli Zaretskii is working on a rewrite of the manual to be placed in the core, so I won't be making any changes to |
Beta Was this translation helpful? Give feedback.
-
All good; I can follow up with Eli.
My current understanding (which I acknowledge may be wrong or otherwise lacking) is that the reasons why it "makes little sense" are:
For (1) I would argue that as there is surely(?) a relevant buffer when The benefit being that setting buffer-local values in mode hooks is very common and well-understood, whereas the current mechanism with the temp buffer is very surprising and going to cause confusion (unless it's clearly pointed out, which is not currently the case). I'm not convinced that I'm right, mind; I merely want things to be easier than they are at the moment, one way or another (said after having spent many, many hours over the past couple of days trying to convince a language server to behave the way I want -- or even just consistently -- and finding the documentation (for both the server and the client) to be much more confusing than I'd hoped for). |
Beta Was this translation helpful? Give feedback.
-
But that mechanism is an implementation detail. You shouldn't need to look at it, as long as you understand that this is a per-project setting by definition (LSP parlance these are "workspaces", hence the name). In Emacs'
What exactly was not easy? The manual has IMO clear examples of how to set directory-local values for this variable, both in Can you post the solution you ended up with? Maybe I can help simplify it and add the example to the manual, presuming it adds something that is not already there. |
Beta Was this translation helpful? Give feedback.
-
Bearing in mind that I started looking at this before the recent commits and documentation updates regarding Part of the problem is that the language servers are dealing with -- and documenting -- JSON, and eglot is documenting plists, and I saw no documented process for correctly converting what would inevitably be a JSON starting point into the correct plist (given the knobs for varying how certain JSON values are handled), which was needed in order to have any confidence that I would be sending the server what I intended to sent (the new command for showing some JSON is a significant improvement in this regard). After digging into the eglot code I found (pp-display-expression (jsonrpc--json-read) "*json*")
{
JSON HERE
} I think there should either be a documented process for doing this (ideally without calling a 'private' function), or otherwise a way to simply pass a JSON string in the first place, because I think that's what most people will actually have to begin with. And if the command for showing the config as JSON isn't showing what they expect, users need to know how to address that. (Edit: Looking again at the updated manual I see that the specific syntax required did actually get documented in the recent changes. I nevertheless believe that some kind of integrated converter would be helpful for users.) (n.b. What that The buffer-local thing genuinely threw me, because it never occurred to me that eglot wasn't simply obtaining the values from one of the file-visiting buffers (again, the temp buffer thing is really unexpected), and so it never occurred to me that there would be a difference between setting that in .dir-locals.el vs in a mode hook. I'd started with a .dir-locals.el file, then later moved this particular variable to a mode hook, and it took me a long time to realise that removing the .dir-locals.el version had caused any breakage. I might well have noticed sooner, but I've been struggling with other failures as well, so this was subtle enough to get lost in the noise of things like the server dying almost immediately after connection (despite working fine earlier in the day). Which means...
...I haven't ended up with anything I'd call "a solution" yet. I also struggled with
I was initially using the latter, and eventually spotted in the events log that the language server was complaining about the language ID being "drupal" despite the fact that I'd set it to "php". This seems like a bug? Anyhow, this is my first foray into using LSP, and when I don't know for sure what the server wants, and I'm also experiencing difficulties making the client send what I thought it was sending, and the visible data format is not JSON, I've been finding debugging to be slow going; so any and all improvements to docs and processes are a win from my perspective. |
Beta Was this translation helpful? Give feedback.
-
Something like that may be acceptable, with buffer-locally replaced by "in the major mode hook", but also think you should wait for Eli's version of the manual. I get it that |
Beta Was this translation helpful? Give feedback.
-
The manual says:
I think that text needs a big caveat attached to it?
I see that this was discussed at length in #967 but to review in brief:
With that latter function call just returning
eglot-workspace-configuration
unless the user has defined a function namedeglot-workspace-configuration
by the looks of it?Notwithstanding the custom function option, setting a buffer-local value for
eglot-workspace-configuration
in the major mode hook for the language (i.e. the typical way of setting a buffer-local value) can't work with this arrangement.I feel that in certain cases it should be absolutely fine to want to do this in a mode hook; but as that's not supported at present I think the manual needs to make it much clearer that the directory-local approach is the only "buffer-local" approach which will work.
Beta Was this translation helpful? Give feedback.
All reactions