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

Formatting parameters (tab size, naming convention) are passed to styler but not lintr #663

Open
brosasaki opened this issue Apr 2, 2024 · 0 comments

Comments

@brosasaki
Copy link

brosasaki commented Apr 2, 2024

An issue I've been having is that using the LS to format code results in immediate errors from lintr, particularly because the parameters sent in DocumentFormattingParams as part of formatting requests do not get used for the parameters of linters. This causes, e.g. the document to be indented according to the specified indent size, but the indentation linter to immediately tag it as wrong because it thinks the indent size is the default 2. Am I missing something here? Is there some way to manually specify the parameters that get sent to calls to linters?

For context, I am using emacs eglot to edit R code. Investigating the eglot code, the package uses the emacs parameter tab-width as part of the document formatting parameters. As things are, setting that width to anything other than the tidyverse 2-space standard causes the aforementioned "correction thrashing".

Edit:
I've found the relevant part of the codebase. It appears that the indent parameter of the indentation_linter is hard-coded to 2 (among other parameters that are left to defaults or hard-coded), when it should change according to the parameters sent to the server, as the DocumentFormattingParams do. The lintr documentation specifies that the linter parameters can be specified on-the-fly with options() or with every call to lint() (which would be consistent with the formatting behavior).

If my prelimary investigation is correct, changing the calls to lint() here to inject the format options with every call would 'fix' the issue (though it might increase memory usage, so using options() might be better). I am not a professional programmer or familiar with this codebase, so I am hesitant to write the patch myself.

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

1 participant