Support for `.Rproj` files

[wurli]

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 <- .

[PMassicotte]

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?

[wurli]

Sorry - accidentally posted this issue mid-edit! Just finishing it now.

[wurli]

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?

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 if R.nvim supported 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.

[jalvesaq]

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?

[wurli]

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 👍

[typhooncamel]

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.

[PMassicotte]

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.