feat: add RStartHorizontal and RStartVertical mappings

[guilhermegarcia]

Summary

• Add <Plug>RStartHorizontal (\rfh) and <Plug>RStartVertical (\rfv) mappings that let users start R with an explicit 50/50 split direction
• Direction is passed as a clean function parameter through start_R → start_R2 → builtin.start → split_window, with no config mutation
• The existing \rf mapping and all config-based split logic remain unchanged

Motivation

Currently, the R console split direction is determined statically at config time via rconsole_width and rconsole_height. Users who switch between wide monitors (prefer vertical) and laptops (prefer horizontal) must change their config manually. These mappings let users choose the split direction at start time.

Design decisions

• 50/50 split is hardcoded — uses math.floor(vim.o.columns / 2) for vertical, math.floor(vim.o.lines / 2) for horizontal. User can resize manually afterwards.
• \rf prefix is extended — \rfh and \rfv build on the existing \rf prefix. With which-key or similar plugins, pressing \rf will show a menu with the available options (\rf for default, \rfh for horizontal, \rfv for vertical). Without such plugins, \rf still fires after timeoutlen.
• Reopen respects direction — If R is already running and the user presses \rfh, the console reopens horizontally.
• No config mutation — Direction is passed as a function parameter, not by modifying the config object.
• Non-builtin terminals unaffected — The split parameter only applies to the built-in terminal path; external terminals ignore it.

Test plan

• Open an R file, press \rfv → R console should appear in a vertical 50/50 split
• Close the R console window, press \rfh → R console should reopen horizontally at 50/50
• Press \rf (wait for timeout) → original config-based split logic still works
• Test with user_maps_only = true → default keys disabled but <Plug>RStartHorizontal/<Plug>RStartVertical still available

[jalvesaq]

Thank you for your pull request! However, we may not need it for the user case that you mentioned. This is part of my R.nvim config:

---@type RConfigUserOpts
local opts = {
    -- Other options here...
}

if vim.o.columns > 200 then
    opts.objbr_auto_start = true
    opts.objbr_w = 60
    opts.rconsole_height = 24
    if vim.env.WEZTERM_PANE then
        vim.env.RTERM = "external"
        opts.external_term = "wezterm_split"
    end
elseif vim.o.columns > 140 then
    opts.objbr_auto_start = false
    opts.objbr_w = 35
    opts.rconsole_height = 20
else
    opts.objbr_auto_start = false
    opts.objbr_w = 25
    opts.rconsole_height = 14
end

require("r").setup(opts)

As you can see, I change not only how the window is split, but also whether I will run R in the built-in terminal buffer or in a WezTerm split pane, whether the Object Browser will start automatically or not, and the width/height of the Object Browser and R Console.

vim.env.RTERM is an environment variable that I use to set the graphicsterminal as the graphic device. This is part of my ~/.Rprofile:

        if (Sys.getenv("RTERM") == "external") {
            options(
                term_background = "#000000",
                term_foreground = "#dddddd",
                term_palette = c(
                    "#cc0403",
                    "#19cb00",
                    "#cecb00",
                    "#0d73cc",
                    "#cb1ed1",
                    "#0dcdcd",
                    "#dddddd",
                    "#767676",
                    "#f2201f"
                ),
                term_col = TRUE,
                device = terminalgraphics::tgp
            )
        }

[jalvesaq]

Your pull request also has changes to r.run.insert_commented()...

[guilhermegarcia]

Good catch — the insert_commented changes were accidentally included in this branch. I've cleaned it up; this PR now only contains the split direction mappings. The insert_commented improvement is in a separate PR (#502).

Regarding the config-time approach: my use case is a bit different — I work in a single terminal window and like to choose the split direction interactively each time I start R, depending on what I'm working on. Since vim.o.columns stays the same either way, the config-time check doesn't help here.

That said, I understand if this is too niche for upstream. Happy to keep it in my fork if it doesn't fit the project's direction.

[jalvesaq]

I work in a single terminal window and like to choose the split direction interactively each time I start R, depending on what I'm working on.

This is a different use case... Let's wait for comments from @PMassicotte (and, possibly, other developers).

[PMassicotte]

I am trying to use this PR.

1. I am not too sure about the timeout/timer when using <localleader>rf, Also, when I use <localleader>rf> I have to press any other key to open the terminal.
2. Using both <localleader> rfv> and <localleader> rfh produce the same on my side. Is this expected or any change in the config should be explicitly made?

[guilhermegarcia]

Thanks for testing @PMassicotte!

Regarding issue 2 (both producing vertical): that's unexpected — it works correctly on my end.

What's your timeoutlen set to?

My suspicion is that \rf might be firing on timeout before the h/v arrives, so R starts with your default config (vertical) and the extra keystroke is ignored.

[PMassicotte]

I am not sure about the delay in <localleader>rf. I also realized that it was not working on my side because I rely on kitty for my terminal and I use kitty config to decide how I open new splits. I guess I was still asleep when I tried the PR ;)

@jalvesaq what do you think?

[jalvesaq]

The delay after typing <LocalLeader>rf is because Neovim is waiting for you to type an additional key to complete either rfh or rfv. See :h timeoutlen.

I'll try the changed code...

[jalvesaq]

It works with external_term="". However, to be part of R.nvim, it should work with all different ways of starting R by splitting a window that we currently support. That is, the same feature would have to work when external_term is "kitty_split", "wezterm_split", or "tmux split-window". This means also implementing the feature in:

lua/r/term/kitten.lua
lua/r/term/tmux.lua
lua/r/term/wezterm.lua

@guilhermegarcia, I know that this means spending your time implementing features that you will never use, but, as a public project, we need to keep it internally consistent. This is why I usually resist adding support for specific R packages or accepting pull requests that implement features that I don't believe will be widely used.

An alternative to implementing this feature is creating a custom key map in your Neovim config that would sequentially run require("r").setup({ your_options_here }) and require("r.run").start_R("R").

[guilhermegarcia]

Thanks for the thoughtful review @jalvesaq. Implementing this across all terminal backends makes sense for consistency, but it's beyond what I can reasonably test on my end. I'll keep this in my fork for personal use.

Thanks @PMassicotte for testing as well!