forbesmyester / xmux.kak

It's like a Frankenstein version of the X11 and tmux REPL's
4 stars 0 forks source link

Mouse wheel scrolls command history in the REPL window instead of scrollback #1

Open Kabouik opened 3 years ago

Kabouik commented 3 years ago

Thanks for this plugin, this is exactly what I needed and I also find it better than x11-repl with the xdotool hack.

I am using it with R as REPL window and Kakoune as script editor. However, I observed that the mouse wheel in the REPL window cycles through the command history in R instead of scrolling back up or down, which would be the normal behaviour in R. I don't think I observed this issue with x11-repl. Are you able to reproduce it or do you think this is a local issue?

forbesmyester commented 3 years ago

Hi,

Thanks for your nice comments :-)

This plugin spawns a TMUX in the new terminal, but with an empty config and then makes it not look like TMUX. I thought this was a great idea, but now I think not so much... because most terminals do different clever things, like mouse wheels.

You could probably fix your problem using a custom TMUX config, if I didn't go ahead and force an empty TMUX config every time...

There's a branch (multi-terminal) where you'd be able to retain a customized TMUX configuration but it's overly complicated, quite undocumented and I'm currently doing a rewrite, which is way simpler and really close to complete. I just need to do more testing...

I'd wait for that new version and give it a go then, though you'll likely still need to look into TMUX for getting your scroll wheel working.

Sorry I can't help more.

I'll update this ticket when the new version is released.

Kabouik commented 3 years ago

Thanks for your answer @forbesmyester. That makes sense, the mouse wheel not scrolling back typically is a Tmux config thing, I don't know why I didn't realize.

I'll happily wait for the new version and use that. xmux-repl still has improved my workflow quite a lot, and x11-repl coincidentally had stopped working in my setup anyway (sending weird characters instead of the text selection; probably an xdotool issue). Do you know already if it will be possible to use a specific Tmux configuration file with your plugin? As far as I remember, Tmux is not very flexible as to where its configuration file is located and enforces ~/.tmux.conf, which may be an issue if I already have a Tmux configuration for the usual Tmux use, but would need different settings when in a REPL situation.

forbesmyester commented 3 years ago

Hi,

I've had a go at finishing of the new version and released it as a new branch.

I may well bundle the xmux utility in at some point, but for the moment I have half a feeling that the tmux scripting stuff is actually useful outside Kakoune... It just needs finishing...

Would love feedback if you have any, good or bad.

Kabouik commented 3 years ago

Good news, thanks! I will give it a try but I'm not sure when yet, as I see that it depends on connect.kak and xmux, so I'll need to alter my config files quite a bit to make all this work together. Keep in mind though that I am not a Kakoune expert at all, so any testing I would do will probably not be as comprehensive as yours.

On 2021-04-23 22:06 Matt Forrester @.***> wrote:

Hi,

I've had a go at finishing of the new version and released it as a new branch.

I may well bundle the xmux utility in at some point, but for the moment I have half a feeling that the tmux scripting stuff is actually useful without Kakoune... It just needs finishing...

Would love feedback if you have any, good or bad.

--
You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/forbesmyester/xmux.kak/issues/1#issuecomment-825891 367

Kabouik commented 3 years ago

[Edit] Alright, I just saw #3 about this problem, checking it right now.

I realized today that xmux.kak doesn't work anymore for me in kakoune, with nothing in the *debug* buffer. Could that be because I updated my packages with plug.kak and it pulled a new version that now depends on connect.kak?

This is what I had in my kakrc:

# Normal mode (no , prefix)
map global normal <c-r> ':xmux-send-text <ret>' -docstring 'Send current selection with xmux-send-text'
map global normal <ret> '<x> :xmux-send-text <ret>' -docstring 'Send line with xmux-send-text'
map global normal <s-ret> '<a-a>p :xmux-send-text <ret>' -docstring 'Send paragraph with xmux-send-text'

# Launch REPL in a new x11 window but use tmux sockets to send text instead of xdotool
plug "forbesmyester/xmux.kak"

Now the commands I set no longer appear in my kakoune prompt. I assume it is because I got the new xmux.kak version and need connect.kak now, I'll look into it. The last time I looked was when you needed feedback but connect.kak seemed a bit overwhelming for a newbie like me, so I postponed (far too long, I'm sorry).

Kabouik commented 3 years ago

After following advice in #3, I could partly fix xmux.kak. However, for some reason, every time I call it with :xmux-repl R R for instance to start a new session named "R" and launch R in it, it opens two new terminal windows. One of them, which I'll call "T1" here is actually running R, and the other which I'll call "T2" just reports duplicate session: R and ends up in the shell.

When I try to send characters or lines from kakoune, "T1" does receive the characters or lines fine, but a third window is opened, doing the exact same thing as "T2".

I'll also need to set keybindings (like described in my previous post) for different types of selections to send, but I am not sure how to work with the fact that xmux.kak's commands can now have different names with :xmux-chars-NAME. Do you have any idea how I could convert my above config to the new system?

I know this is a bit unrelated to the topic of this issue, but since we were discussing feedback on the multi-terminal support before, I'm answering here. I'm happy to open a specific issue if you prefer, please let me know.

forbesmyester commented 3 years ago

To be honest I'm no longer dogfooding :xmux-repl R R. I realize I'm separating my creation and interaction steps.

The thinking is that you create a name with xmux-repl NAME and then you interact with it via xmux-chars-NAME or xmux-lines-NAME depending on if you want to send lines or chars.

I did have a race condition (something to do with tmux titles) occurring very rarely that caused duplicate sessions, I fixed it a while ago, but I actually pushed the fix this morning.

Can you let me know if that fixes your issue or if you can separate your workflow's create / interact stages?

xmux-repl NAME CMD does actually work for me but I did consider removing the CMD parameter from xmux-repl recently...

forbesmyester commented 3 years ago

Also pushed a dogfood branch of xmux which removes the title setting requirements, so solely uses tmux for interop, so may be more reliable on other desktops. Your :xmux-repl R R will likely work well with this version.

Kabouik commented 3 years ago

Thanks for the follow-up @forbesmyester. Unfortunately, I tried switching from your older xmux.kak repository to the new xmux, but I can't see the associated commands in Kakoune.

I installed it with plug "forbesmyester/xmux" in my kakrc and could confirm that ~/.config/kak/plugins/xmux was created and contained an executable xmux. Since it didn't work, I tried symlinking that folder to ~/.config/kak/autoload/xmux because I know this is something that worked with the older xmux.kak (see above), but that didn't do it either.

~/.config/kak/plugins/xmux/xmux is also symlinked to my PATH.