> On Mar 5, 2023, at 4:16 PM, João Távora <joaotavora@gmail.com> wrote:
> 
> Yuan, please show the patch to Eglot's manual and let's work from
> there.

I’m not an amazing writer, but here it is.

> 
> I'm also OK with adding more examples, and work on simplifying the
> per-project configuration workflow, maybe by somehow making it
> easier to translate that dotted path notation into the nested JSON
> object that the server is ultimately looking for.

I feel that explaining the relationship between the dotted notation, the JSON object and the plist value that eglot accepts is already some cognitive load. And adding a translator into the mix will make it worse. If we provide the translator but don’t explain how it works, it will be just as confusing. But I could be wrong, I didn’t ponder this too deeply.

> By the way, it's per-project server configuration that you're
> presumably after when looking at eglot-workspace-configuration,
> NOT per-user.
> 
> A per-user thing would be :initializationOptions or custom
> command-line arguments in eglot-server-programs, or even a
> special ~/.foorc file that the server reads (rust analyzer doesn't
> seem to have one, though, but clangd does).  The reason I bring
> up the distinction is that, in many cases (but not all of course),
> the user is actually interested in that, but strays from
> the objective and ends up the same configuration over all her
> different projects.
> 

You are right, I was following an old GitHub issue that uses workspaceConfiguration and sends it as a initializationOption. 

> If this distinction is not clear in the manual, either, it should
> be made so.

initializatiOption is only mentioned in the documentation of eglot-server-progrems, while workspaceConfiguration has a dozen paragraphs devoted to it. So maybe it’s easy to take workspaceConfiguration as the “main” way to configure a server. Maybe we can spend a little bit of text noting initializationOption under the “Customizing eglot” section.

> 
> Reading the docs, rust-analyzer allows per-user configuration via
> :initializationOptions.  The syntax and supported options are
> usually the same but the difficulties and confusion associated
> with ~/.dir-locals.el are not there.
> 
> João