Support for `.Rproj` files
wurli opened this issue · 7 comments
RStudio uses these files to keep track of project settings, and to set the working directory when opening a project. I'd guess that most R.nvim users won't be using RStudio, but will be working with people who do, so perhaps it's worth thinking about taking account of these somehow.
There's no official documentation for the .Rproj file format, but it's essentially a debian control file, and the code used by RStudio to parse them is also available on GitHub.
These are some configurable options which I think could be useful in R.nvim:
| Field | Description |
|---|---|
| Version | I think this relates to the version of RStudio used to create the project - probably could be ignored by R.nvim |
| RVersion | The R version used by the project. AFAIK, R.nvim doesn't use project-specific R versions, but could perhaps warn the user if the R version in use doesn't match this? |
| RestoreWorkspace | Whether to restore the user's workspace on startup |
| SaveWorkspace | Whether to save the user's workspace on exit |
| AlwaysSaveHistory | Whether to save a .RHistory file for the project |
| UseSpacesForTab | Whether to use spaces for tabs |
| NumSpacesForTab | The number of spaces for tabs - IMO this would be a nice one to set for R buffers on startup |
| AutoAppendNewline | Whether to automatically append a trailing blank line on save |
| StripTrailingWhitespace | Whether to strip trailing whitespace on save |
| LineEndingConversion | Controls whether to use different line endings than the system default |
| UseNativePipeOperator | Whether to use the native pipe operator instead of %<% with the RStudio shortcut. I guess this would only be useful if R.nvim provided a native mapping as it does with <- . |
As far as I use it in my projects, r version is registered in renv.lock file and restoring the workspace is not really recommended. Do you have a use case where this could be useful?
Sorry - accidentally posted this issue mid-edit! Just finishing it now.
As far as I use it in my projects, r version is registered in
renv.lockfile and restoring the workspace is not really recommended. Do you have a use case where this could be useful?
I think the main benefits for me would be:
- Project-specific styling settings, particularly tab width and line ending conversion.
- Whether to use the native pipe operator. I set a keymap for this in Neovim, but it's a bit of a pain when switching between projects which use
%<%. I'd really like it ifR.nvimsupported a native keymapping, but that would only really be a big win if this was dynamic between projects.
I agree regarding saving the workspace - I've never found a good reason to have this happen automatically. Saving .RHistory I'm less sure on - I rarely use it in practice.
Currently, ftdetect/r.lua only sets the option syntax=yaml for *.Rproj files (we can change the syntax to Debian control if more appropriate).
To implement what you are requesting, we would have to add a function with a name such as "check_rproj" in a new Lua script (lua/r/rproj.lua) and call it in each of our ftplugin/*_rnvim.lua scripts. The function would read the .Rproj file if it exists, and change Neovim and R.nvim configurations accordingly. Are you willing to do a pull request for this?
Happy to make a pull request - likely will be some time in the next couple of weeks. Thanks for suggesting an approach - glad you think it's worth looking at 👍
Can I suggest providing access to an option whether to check or not? Sometimes I work on others' repositories, and they add .Rproj files, but I don't think I would want to use their settings, or R.nvim to automatically change settings as a result of that.
Can I suggest providing access to an option whether to check or not? Sometimes I work on others' repositories, and they add .Rproj files, but I don't think I would want to use their settings, or R.nvim to automatically change settings as a result of that.
This will be 100% like that. Opt-in or not option.