Passing lintr options to ESS from the configuration. about spacemacs HOT 3 OPEN

In many cases either way should work: Setting variables in the layer declaration, or using setq or setopt forms in dotspacemacs/user-config.

Some ideas, though I do not use ess regularly myself:

1. Fix the the value of ess-r-flymake-linters by escaping the inner quotation marks:

'("object_name_linter(\"CamelCase\")")

2. If flycheck is enabled in ess-r-mode due to the syntax-checking layer, disable it: (It can also be toggled in a buffer with SPC t s.)

   (setopt flycheck-global-modes (remove 'ess-r-mode flycheck-global-modes))

from spacemacs.

I don't know if I'm interpreting 2 correctly, does it imply that I need to take care not two packages are calling for the linter at the same time? Something like a more global one ignoring my config might be taking over?

from spacemacs.

In this particular case, the main problem I see is that the variable ess-r-flymake-linters only applies to flymake, and flycheck would still use some default (in my case snake_case instead of CamelCase). This means that CamelCase variables would still be highlighted as errors, even though flymake is configured correctly. One could probably also configure flycheck analogously.

However I'm not sure if it ever makes sense to have both flycheck and flymake enabled: I would assume that one of the two packages should suffice for linting a particular buffer at a time and they seem to be alternatives. The ess package will enable flymake by default, which can be configured with the variable ess-use-flymake. If the syntax-checking layer is used (which is always the case if the lsp layer is active), the ess layer will enable flycheck-mode in ess-r-mode-buffers, without disabling flymake. I am not sure whether this is an issue with the ess layer, perhaps someone else actually using it would know.

Have you already tried if the above solves your problem? It seems to work for me.

from spacemacs.