> Hmmm.  I don't use "pylint" but what sense does it make to disable it
> entirely (supposedly, that's what :enabled :json-false does) and then
> _also_ pass args to it.  Should we just enable it?  This is all pretend,
> of course.  But shouldn't it make more sense?

Ooops. I had simply looked through the available pylsp options [1] seeing which are of array type and would fit into the example plist that we already have. But you're right it doesn't make much sense here [2].

Instead, I would prefer to set some other array option from [1]. There are many more plugin options, but most of them are better set in python project configuration files (including the earlier pylint args), so personally I never use them.

In the now attached patch v3 I set `pylsp.plugins.jedi_completion.cache_for', as we already have a :jedi_completion key (and it's enabled). By default it caches ["pandas", "numpy", "tensorflow", "matplotlib"]. One might want to extend the default list, but to keep the example short I just set it to a subset of the default. What do you think about that?

[1]: See https://github.com/python-lsp/python-lsp-server/blob/develop/CONFIGURATION.md

[2]: When I'm pedantic (:pylint (:enabled :json-false)) also doesn't do anything since pylint is disabled by default, but I see some value in being explicit so I think for an example it's fine.

> "Lisp" should be capitalized (pedantically, "Elisp", since vectors in
> other dialects have different read syntax, but Lisp is fine)

In the patch below I use "Elisp vectors" now.

I would be fine with you editing the patch if you find some minor things to improve or have a better idea for the example. Git commits can have co-authors (this is what github does when you accept suggestions from reviewers), but not sure how the typical workflows are on emacs-devel (I just recently joined to keep up-to-date with recent developments). Or should the patch submitter must aggregate all suggestions into a final patch themselves?

> I'll push the patch soon it with a
>
>   Copyright-paperwork-exempt: Yes
>
> cookie, since this seems to fall under the "trivial" basket, but you
> should probably get a FSF copyright assignment for future contributions.

I'll try that soon. This patch changes just a couple of lines of documentation, so I hope it's fine for now. Slowly I'm figuring out this mailing list workflow and with the copyright assignment, there would be no hurdles for larger contributions to Emacs in the future :)

Michael Eliachevitch