Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing lintr options to ESS from the configuration. #16375

Open
duarteoctavio opened this issue Apr 25, 2024 · 3 comments
Open

Passing lintr options to ESS from the configuration. #16375

duarteoctavio opened this issue Apr 25, 2024 · 3 comments

Comments

@duarteoctavio
Copy link

Issue

I need to configure some ESS (emacs speaks statistics) variables.
My intention is to configure the linter to accept CamelCase variable names.
I'm not fluent in Elisp (I intend to ammend that, but now I need to finish some work).

What I know so far

I need to pass the value linters_with_defaults(object_name_linter = "CamelCase") to ESS's ess-r-flymake-linters option.
For a similar ssue, in the ESS wiki, they seemingly set a parameter in a non declarative way, which I believe is not how you do it in .spacemacs.
What they do is (setq ess-r-flymake-linters '("line_length_linter = line_length_linter(120)")).

My attempt

In .spacemacs.

dotspacemacs-configuration-layers (
  (ess :variables
      ess-r-backend 'lsp
      ess-r-flymake-linters '("object_name_linter("CamelCase")")
    )
)

Result

My CamelCase variables are still highlighted as errors, so I assume ESS is not receiving the parameters I intend to send.

@fnussbaum
Copy link
Contributor

fnussbaum commented Apr 26, 2024

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\")")
  1. 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))

@duarteoctavio
Copy link
Author

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?

@fnussbaum
Copy link
Contributor

fnussbaum commented Apr 26, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants