search

numToStr / Navigator.nvim

:sparkles: Smoothly navigate between neovim and terminal multiplexer(s) :sparkles:
MIT License
391 stars 21 forks source link

[feat] Adding support for wezterm #17

Closed marty-oehme closed 1 year ago

marty-oehme commented 1 year ago

I am currently in the process of replacing my tmux setup with the integrated mux capabilities of the wezterm terminal. One of the pieces missing was an easy replacement for the cross-nvim/tmux movement functionality provided by this plugin.

Since wezterm is in the process of adding pane movement functionality to its cli (similar to tmux), I am currently extending this plugin to work with wezterm here. As of now, basic movement works but there are some kinks to iron out with last-panel movement and client detection (they are simple hacks just to get it to work atm) and the setup instructions are still a mess.

Before I go much further, I wanted to ask if you could foresee yourself adding the maintenance of such additional functionality to this plugin or rather not?

If so, I would take some time to polish up a PR with the added functionality, but if not I would try to fork the project to maintain a version for wezterm instead.

Whichever way you decide, thanks for your work on the plugin so far!

numToStr commented 1 year ago

Yes, definitely I am open to add support for different multiplexers/terminal-with-pane. We just need to 1) decide precedence, for cases like tmux inside wezterm and 2) a nice interface to interact with different multiplexers.

marty-oehme commented 1 year ago

Happy that we can consider the inclusion! My current thinking was to favor tmux unless you specifically select wezterm in the setup, since it is harder to detect the terminal emulator automatically anyway as far as I know.

But then - will work out the currently remaining hacks of the implementation for a bit and then prepare a PR where it might be easier to discuss interface implementation?

numToStr commented 1 year ago

My current thinking was to favor tmux

I also have the same opinion. We need to give mux priority over terminals, whether tmux or zellij.

But then - will work out the currently remaining hacks of the implementation for a bit and then prepare a PR where it might be easier to discuss interface implementation?

Yes, definitely. Code is better than words :D. The idea is, Navigator (API or Commands) is the user interface, which is already there and Multiplexer/Terminal Interface is the internal implementation. Then, We can have a detection code in .setup(); when the user uses API or command, we can delegate that to correct internal implementation.