Adding bracketed paste option for wezterm

[MadFisa]

A fix for issue #373. Implements option to turn on and off bracketed paste for wezterm.

[albheim]

Looks reasonable, and "works" for the cases I tested. Though the double enter annoys me.

Especially since it seems like it does not do it from only wezterm, i.e.

echo ls | wezterm cli  send-text --pane-id=18 --no-paste

correctly runs ls in pane 18 for me, and it must be the vim-slime that adds an extra newline for some reason.

Might be less disruptive for people who use this to have bracketed paste on by default since that is how it was before? Though maybe it is nicer to align with tmux settings, dont have a strong opinion here.

[MadFisa]

Though the double enter annoys me.

My guess is that the first enter is caused by a:text which probably has a newline character appended to be used with tmux. echo probably adds another newline character on top of that resulting in double enters. Confirming this would require someone with better knowledge of vim script than me to look into it.

One solution that could be tried is to try echo -n which won't add the extra endline, but '-n' flag is not apparently not a standard in all distros and could have unexpected behaviour. People suggestprintf has alternative, but on trying it out I found that you may have issue with lines that start with '%' (like '%cpaste -q' used in ipython).

Other options is to try directly substituting in wezterm command, but as I mentioned in #373, it creates other issues.

Might be less disruptive for people who use this to have bracketed paste on by default since that is how it was before? Though maybe it is nicer to align with tmux settings, dont have a strong opinion here.

I think sticking with tmux defaults would be better. Especially if these options are being added to other targets also, I believe it is better to have the same unifying, documented default.

[albheim]

What about trying to work in this bit also? Seems like it would deal with exactly removing the trailing stuff. https://github.com/jpalardy/vim-slime/blob/e5ae6a6d479c97d5352969574130956798e480b7/autoload/slime.vim#L142-L149

Though it would actually need to run in both cases, not only in bracketed mode, if we want to get rid of the double enter we see.

[jpalardy]

Hi there

I’m following this, but I’m away from the computer for the week

I’ll reply properly next weekend

On Wed, Apr 5, 2023 at 03:51 MadFisa @.***> wrote:

@.**** commented on this pull request.

In autoload/slime.vim https://github.com/jpalardy/vim-slime/pull/374#discussion_r1158551616:

• call system('screen -X colon " +"')

Thanks for catching it. I don't know what happened there. I was using codespaces to make those edits.

— Reply to this email directly, view it on GitHub https://github.com/jpalardy/vim-slime/pull/374#discussion_r1158551616, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAENXV6NCAHXT3QLY5PRSTW7V2GXANCNFSM6AAAAAAWSZGVWA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[MadFisa]

What about trying to work in this bit also? Seems like it would deal with exactly removing the trailing stuff.

https://github.com/jpalardy/vim-slime/blob/e5ae6a6d479c97d5352969574130956798e480b7/autoload/slime.vim#L142-L149

Though it would actually need to run in both cases, not only in bracketed mode, if we want to get rid of the double enter we see.

I tried it. Specifically the part that strips out the trailing endline character. It works but introduces a new problem with slime_python_ipython option, where it causes ipython console to freeze up while sending '--'. Not sure what is happening there.

[MadFisa]

This reminds me of what happened here here. Basically same effect can be achieved with just using call system("wezterm cli send-text --no-copy --pane-id=" . shellescape(a:config["pane_id"]). ' '. shellescape(a:text) ) instead of echo, basically not adding an extral endline by echo.

Maybe there is something that happens with '--' (or g:slime_python_ipython option) and endline combination?

[MadFisa]

@albheim @jpalardy So I figured out the problem and kinda have a solution. All the methods that removes that extra endline ( removing echo, removing using the tmux code snippet) causes an issue when using with g:slime_python_ipython when sending multiple lines. For some reason, '--' is not send to ipython console, if there is not a (extra?) endline before '--'. I tried and added an extra endline ftplugin/python/slime.vim before the '--' and it seems to have fixed the problem. I tested with wezterm and limited testting with tmux haven't found any problems so far. But since this requires modifying code that is not just specific to wezterm, I will leave this to your discretion on whether to merge or not.

[jpalardy]

Hi @MadFisa @albheim

I downloaded wezterm and I'm going to experiment a bit.

Let me get back to you with my findings.

[jpalardy]

@MadFisa @albheim

I took a shot at it with #375, please have a look

If that works for you, I'll integrate the documentation from this PR into it

I tried this both with g:slime_bracketed_paste = 1 and g:slime_bracketed_paste = 0 (as per tmux's reference)