I don't think you've considered how bad the design of the feature is.

If a program terminates by accident in the wrong state, other software
running afterwards is unaware that the session is behaving incorrectly,
and there are some dangerous conditions that a user cannot recover from.

(There are other tty-related things which have similar issues; our
handling of this is to avoid creating more of a mess)

Kyle Markley <k...@arbyte.us> wrote:

> There is a second layer of defense present: xterm can be configured at
> runtime, through its disallowedWindowOps resource, to enable or
> disable the SetSelection and GetSelection operations individually.
> 
> I think it would be more user friendly to have this feature compiled
> in, but left disabled by default via disallowedWindowOps.  It was not
> user friendly for SetSelection and GetSelection support to be absent
> without any hint of their removal in the xterm man page.
> 
> These options would not need to be enabled in ~/.Xresources, but could
> be enabled only as needed e.g. with xterm -xrm stuff -e tmux, and tmux
> configured with set-clipboard external (rather than on).  I think this
> would give clipboard access only to tmux but not the applications
> within it.
> 
> 
> On 4/18/24 10:14, Theo de Raadt wrote:
> > It is an extremely dangerous anti-feature.
> >
> >> I observed that in OpenBSD 7.5, the configuration of xterm is such that
> >> xtermcfg.h gets #define OPT_PASTE64 0.  A consequence of this is that
> >> OSC 52 support is compiled out, and a consequence of that is that tmux
> >> cannot set the primary X selection (for copying text out of a tmux pane)
> >> via its set-clipboard option, which uses OSC 52.
> >>
> >> I encountered this problem as a frustrating silent failure after
> >> following the instructions at the tmux wiki
> >> (https://github.com/tmux/tmux/wiki/Clipboard).
> >>
> >> Is there a reason that paste64 is configured out, or could we change
> >> this (e.g. with --enable-paste64) so that OPT_PASTE64 is 1?
> >>
> >> -- Kyle Markley
> >>
> >>
> 
> -- 
> Kyle Markley
> 

Reply via email to