Support WezTerm mux splits

[JonGretar]

I'm not quite familiar with how R.nvim handles external_term but I would love to be able to open R in a WezTerm pane much like in a tmux pane. This should work for darwin much like tmux.

I guess in a Linux machine I could just set the full command but I am not sure why it is not allowed for darwin. I'm sure there are good reasons but I don't know why this would not be possible with WezTerm much like with tmux.

The command to run would be something like wezterm cli split-pane --bottom --percent 30 -- R

[jalvesaq]

It's possible with Kitty. Please, see the last comments on #115. You can try to adapt the solution for WezTerm.

[JonGretar]

It's possible with Kitty. Please, see the last comments on #115. You can try to adapt the solution for WezTerm.

As I understand it. Then on MacOS R.term only allows true or some tmux command in external_term. Am I incorrect about this? Actually the docs don't mention allowing tmux but it seems it does.

[JonGretar]

Got this working by lying to R.nvim about being on a mac.

    local options = {
      is_darwin = false,
      external_term = 'wezterm cli split-pane --bottom --percent 30  -- ',
      R_app = 'radian',
    }

[jalvesaq]

Thanks for sharing your solution!

The last time that I tried Nvim-R on a Mac was in 2015, and, as far as I remember, OS X always started R in whatever was the default terminal. Did macOS inherit this feature (or limitation)? You, people who have access to a macOS, can decide whether the is_darwin config option is still necessary or not.

[jalvesaq]

Another option that I don't know if still works on macOS is applescript = true.

[JonGretar]

Thanks for sharing your solution!
The last time that I tried Nvim-R on a Mac was in 2015, and, as far as I remember, OS X always started R in whatever was the default terminal. Did macOS inherit this feature (or limitation)?

This seems to be a design choice that R.nvim itself makes. By using the open command to launch when external_term is set to true. The open command simulates what would happen if double click on the file in the GUI file finder unless it is set to tmux. But as I am using a command to interface to the terminal that NVim is running in this does not seem to work so well.

I guess this comes down to the capability of modern terminals on macOS these days. Back in 2015 the choice was the default terminal or iTerm. But in modern times with newer terminals, some of which with their own mux, and alternatives to tmux such as zellij this system might need to be reconsidered.

[jalvesaq]

Could you make a pull request for this?

[DanielHermosilla]

Got this working by lying to R.nvim about being on a mac.

    local options = {
      is_darwin = false,
      external_term = 'wezterm cli split-pane --bottom --percent 30  -- ',
      R_app = 'radian',
    }

Thanks a lot, that worked for me too in MacOS. Having that fixed, my main problem goes to the external terminal not recognizing the R session of Nvim (which implies that I can't send my code)

Wondering also, what are the downsides for tricking R.nvim to thinking i'm using another OS?

[jalvesaq]

Wondering also, what are the downsides for tricking R.nvim to thinking i'm using another OS?

Any answer for this question? If there is no problem, I can remove the macOS limitation.

Does wezterm work on Windows too? If it does work on both Windows and macOS we could remove the support for running Rgui.exe (on Windows) and R64.app (on macOS).

[PMassicotte]

Does wezterm work on Windows too? If it does work on both Windows and macOS

I think so:

• https://wezfurlong.org/wezterm/installation.html

[jalvesaq]

@PMassicotte, could you please tell me what happens on macOS with these options:

applescript = true,
external_term = "default",

It should open R64.app which used to be the only way of running R in a separate window on OS X (tested in 2014). Since it's now possible to choose what terminal emulator to run, can we drop the support for R64.app or do you think that some people will still prefer to run it instead of plain R in a terminal emulator?

[PMassicotte]

@PMassicotte, could you please tell me what happens on macOS with these options:

applescript = true,
external_term = "default",

I am on Linux :)

It should open R64.app which used to be the only way of running R in a separate window on OS X (tested in 2014). Since it's now possible to choose what terminal emulator to run, can we drop the support for R64.app or do you think that some people will still prefer to run it instead of plain R in a terminal emulator?

I think this is fair to not support Rapp. I think that most R.nvim users are more interested in the full terminal experience. I would be surprised if many are using the Rgui. What do you think?

[jalvesaq]

I think the same. I'll add warnings that support for Rgui.exe and R64.app will be removed unless users manifest interest in using them.

[MyntaNorberg]

applescript = true,
external_term = "default",

It should open R64.app which used to be the only way of running R in a separate window on OS X (tested in 2014). Since it's now possible to choose what terminal emulator to run, can we drop the support for R64.app or do you think that some people will still prefer to run it instead of plain R in a terminal emulator?

I just tried this on MacOS now and it still works as you intended. I agree above with the discussion that this is probably of little interest. The native mux split in Wezterm works for me too, and I also need the is_darwin=false. Without it, Neovim indicates that the call to start_R2 in R.nvim/lua/run.lua doesn't finish. Not sure why.

I personally prefer a separate window instead of a split. For this, the following seems to work well for me. As such, WezTerm multiplexing seems be well supported at the moment.

is_darwin = false,
external_term = 'wezterm cli spawn --new-window '

[jalvesaq]

Not sure why.

It's because in 2014, when I had the opportunity to keep an OSX laptop with me for a week to adapt the Vim-R-plugin, the system always opened iTerm regardless of how I configured the external terminal emulator.

You should no longer need is_darwin = false...

[jalvesaq]

I just tried this on MacOS now and it still works as you intended.

Thanks for trying!