Clipboard challenges

[Kyle Markley]

Hello,

I have only been using tmux for a couple weeks, but I am loving it.  I want to keep similar configurations at home and at work, but one of those environments is giving me clipboard trouble.

I have followed the wiki clipboard instructions (https://github.com/tmux/tmux/wiki/Clipboard) to synchronize with the system clipboard using the OSC 52 method.  At work, on a Linux system, it's working great.  But at home, on OpenBSD 7.5, it isn't.

In both environments my terminal is xterm, I have set-clipboard set to external, the Ms capability is set, and I'm setting XTerm*disallowedWindowOps as required.  But uniquely on the OpenBSD system, I cannot copy from inside tmux and paste outside tmux, or vice versa.  What is my next step to debug this?

[Nicholas Marriott]

Are you sure xterm has seen the resource change? What if you load the file manually with xrdb? If you open the xterm menu and tick "Allow Window Ops" does it work?

Are you sure it is copying to the selection you expect? You can check by installing xsel on the local host and running xsel -b/xsel -p and see if you see what you copied.

--
You received this message because you are subscribed to the Google Groups "tmux-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tmux-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/60dffb50-7020-4cdf-b36e-8722f40606fdn%40googlegroups.com.

[Kyle Markley]

Hello,

I believe that the xterm has seen the resource change.  I found a tool 'xgetres' to see the resource, and it says:

$ ./xgetres "XTerm*disallowedWindowOps"
20,21,SetXprop

This agrees with appres:

$ appres XTerm | grep disallowed
XTerm*disallowedWindowOps:      20,21,SetXprop

Checking AllowWindowOps in the xterm menu makes no difference.  According to xsel (-p, -s, -b), selecting text within tmux never writes to any X selection.  Selecting text outside of tmux writes the primary selection.

You received this message because you are subscribed to a topic in the Google Groups "tmux-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tmux-users/kLeXXgfE9eA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tmux-users+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/CAEdLfcEptqODjsriktD%3DgDKjE4xDedU13Nr8WyOER_OAf233kw%40mail.gmail.com.

-- 
Kyle Markley

[Kyle Markley]

I have root caused why OSC 52 is not working on OpenBSD 7.5

It turns out that xterm is being configured with #define OPT_PASTE64 0, so the OSC 52 support is simply not present.  If I reconfigure it with --enable-paste64, then it works!  I have not figured out how to do the configuration completely correctly, as I'm ending up with a lot more changes than just OPT_PASTE64, but if I get that figured out then I'll be able to replace my system's xterm.

On 4/14/24 16:09, Kyle Markley wrote:

I've compared the debug logs (tmux -v) between working and failing systems and don't see much different.  I even see my copied text and the OSC 52 code in the log.

1713135904.430384 message: /dev/ttypb key MouseDragEnd1Pane: send-keys -X copy-pipe-and-cancel
1713135904.430388 cmd_find_from_client: s=$0 0
1713135904.430395 cmd_find_from_client: wl=1 1 w=@0 [tmux]
1713135904.430398 cmd_find_from_client: wp=%0
1713135904.430400 cmd_find_from_client: idx=none
1713135904.430403 cmd_find_target: target none, type pane, item 0x6e431cb7300, flags NONE
1713135904.430406 cmd_find_target: current is from queue
1713135904.430408 cmd_find_target: s=$0 0
1713135904.430411 cmd_find_target: wl=1 1 w=@0 [tmux]
1713135904.430412 cmd_find_target: wp=%0
1713135904.430414 cmd_find_target: idx=none
1713135904.430419 cmd_mouse_at: x=14, y=0
1713135904.430422 screen_write_start_pane: size 113x67, pane %0 (at 0,0)
1713135904.430425 screen_write_cursormove: from 14,0 to 14,0
1713135904.430429 screen_write_collect_flush: flushed 0 items (screen_write_stop)
1713135904.430439 utf8_to_data: 41000021 -> (1 1 !)
1713135904.430442 utf8_to_data: 41000021 -> (1 1 !)
1713135904.430444 utf8_to_data: 41000048 -> (1 1 H)
1713135904.430446 utf8_to_data: 41000069 -> (1 1 i)
1713135904.430448 utf8_to_data: 41000020 -> (1 1  )
1713135904.430450 utf8_to_data: 4100006d -> (1 1 m)
1713135904.430452 utf8_to_data: 4100006f -> (1 1 o)
1713135904.430454 utf8_to_data: 4100006d -> (1 1 m)
1713135904.430459 utf8_to_data: 41000021 -> (1 1 !)
1713135904.430461 screen_write_start_pane: size 113x67, pane %0 (at 0,0)
1713135904.430569 /dev/ttypb: \033]52;;SGkgbW9tIQ==\a

I suppose this means that the problem is in the receiving side -- in X, not in tmux.  Is there some configuration that I need to do here on OpenBSD that is default behavior on Linux?

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/bfc6342e-3217-4f2e-8d4f-96a9eccc00d3%40arbyte.us.

-- 
Kyle Markley

-- 
Kyle Markley

[Kyle Markley]

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/bfc6342e-3217-4f2e-8d4f-96a9eccc00d3%40arbyte.us.

-- 
Kyle Markley

[Nicholas Marriott]

Hmm OK this seems like either an oversight or something I missed because it definitely used to work (just off by default).

To view this discussion on the web, visit https://groups.google.com/d/msgid/tmux-users/342fb954-5eee-40d7-841a-d2e67eadd931%40arbyte.us.