Shouldn't eglot-workspace-configuration be safe as a function symbol when setting its directory-local value?

[galeo]

As its docstring describes, the directory-local value of eglot-workspace-configuration can be set to a unary function. However, the code does not correspond to this description.

;;;###autoload
(put 'eglot-workspace-configuration 'safe-local-variable #'listp)

Is this intentional or does it need to be adjusted?

[joaotavora]

Well generally, things that are functions aren't really safe when used as file or directory local variables, because functions have side-effects, at least how I understand what "safe" means in this context. But I'm definitely not an expert. But just imagine I give you a project to work on with a directory local definition of e-w-c with a function (lambda (&rest _ignore) (spawn-malware)) and tell you to run M-x eglot on it.

[joaotavora]

Because if it is multiple === all, you'd be better served by the methods described here: https://joaotavora.github.io/eglot/#User_002dspecific-configuration. Actually start by reading: https://joaotavora.github.io/eglot/#Advanced-server-configuration-1.

There are three distinct methods described available to you: server-specific RC files, command-line options and LSP initializationOptions. Do investigate if your server supports any of them.

Another entirely-different thing is project-specific configuration https://joaotavora.github.io/eglot/#Project_002dspecific-configuration-1. Many times, many users are trying to (ab)use eglot-workspace-configuration to achieve user-specific per-server configuration, when in effect this "workspace configuration" was intended -- by LSP, not by Eglot -- as a means of project-specific configuration.

Nevertheless this abuse can be achieved by Eglot, just search for setq-default within that section

[galeo]

Thanks for the summary. The setq-default way will cause errors in some lsp servers, such as zls, which will cause a segmentation fault when it receives additional setting items.

[joaotavora]

Thanks for the summary. The setq-default way will cause errors in some lsp servers, such as zls, which will cause a segmentation fault when it receives additional setting items.

I didn't know that. It could be that this is a bug in the zls server, but I'm not sure what the standard says about that.

Anyway, the setq-default way, can still be done, right? just:

(setq-default eglot-workspace-configuration #'function-that-doesnt-send-items-other-the-ones-server-wants)

[galeo]

Although this method is somewhat of a hack, it is helpful. Thanks.

[joaotavora]

Although this method is somewhat of a hack, it is helpful. Thanks.

Using a mechanism for project-specific configuration to accomplish user-specific, per-server configuration is a hack.