[qubes-users] Can no longer copy text from xterm by default

I used to be able to be able to do the following to copy text from xterm in Fedora and Debian VMs:

1. Select/highlight the desired text, thereby inserting it into the PRIMARY buffer.

2. Press <Ctrl + middle mouse button> in order to bring up a menu (I think it was the "VT Options" menu).

3. In this menu, select the option to copy text from the PRIMARY buffer to that VM's local clipboard.

4. Press <Ctrl + Shift + C> to copy text to the Qubes inter-VM clipboard and proceed as usual.

However, some time ago, step 2 suddenly stopped working, and I have no idea why. Pressing <Ctrl + middle mouse button> in xterm now does nothing, as far as I can tell. I've checked my trackpad/mouse settings, and everything seems fine and unchanged. I've tried pressing the left and right mouse buttons simultaneously instead, but nothing.

I know that I can probably create custom xterm settings that will allow me to copy text, but I'd still like to know whether there's a way to do it by default for cases in which the VM is uncustomized. Does anyone know if there is such a way?

On Debian you can hold down the Ctrl key before pressing the button, to get the
VT options menu. See if that works for you. Does for me.

I never used that, but here for the fedora-32 template it works.
I think you can override bindings inside the app via X resources, but my suspect is that the window manager "captures" the mouse or key event, so it does not arrive at the terminal any more.

Regards,
Ulrich

No, that's exactly the behavior I described as no longer working for me. <Ctrl + middle mouse button> means the same thing as holding down Ctrl before pressing the middle mouse button.

I'm confused. You say it's working in the Fedora 32 template for you, yet you also say the key event is captured, so it's not arriving at the terminal anymore. How can it be working for you if the key event is being captured by the window manager?

In my experience, holding a key down *before* another action does not
always work the same as performing both actions simultaneously, so I
did not think that these "meant the same thing".
Can you call up the Main options, and Font menus using buttons 1 and 2?

Add "XTerm*selectToClipboard:true" to ~/.Xdefaults and you need not
invoke the menu

I used to be able to be able to do the following to copy text from xterm in
Fedora and Debian VMs:

1. Select/highlight the desired text, thereby inserting it into the PRIMARY
buffer.

2. Press <Ctrl + middle mouse button> in order to bring up a menu (I think
it was the "VT Options" menu).

3. In this menu, select the option to copy text from the PRIMARY buffer to
that VM's local clipboard.

4. Press <Ctrl + Shift + C> to copy text to the Qubes inter-VM clipboard and
proceed as usual.

However, some time ago, step 2 suddenly stopped working, and I have no idea
why. Pressing <Ctrl + middle mouse button> in xterm now does nothing, as far
as I can tell. I've checked my trackpad/mouse settings, and everything seems
fine and unchanged. I've tried pressing the left and right mouse buttons
simultaneously instead, but nothing.

I know that I can probably create custom xterm settings that will allow me
to copy text, but I'd still like to know whether there's a way to do it by
default for cases in which the VM is uncustomized. Does anyone know if there
is such a way?

On Debian you can hold down the Ctrl key before pressing the button, to get the
VT options menu. See if that works for you. Does for me.

No, that's exactly the behavior I described as no longer working for me.
<Ctrl + middle mouse button> means the same thing as holding down Ctrl
before pressing the middle mouse button.

In my experience, holding a key down *before* another action does not
always work the same as performing both actions simultaneously, so I
did not think that these "meant the same thing".

Ah, interesting. In my experience, they've always meant the same thing in the context of computing, but I suppose it's possible that some systems treat them differently.

Can you call up the Main options, and Font menus using buttons 1 and 2?

Yes, those are still working as expected.

Add "XTerm*selectToClipboard:true" to ~/.Xdefaults and you need not
invoke the menu

Right. As mentioned above, I'm aware that I can customize the xterm settings in order to able to copy text, but I'd still like to know whether there's a way to do it with the default settings for cases in which the VM is uncustomized.

I used to be able to be able to do the following to copy text from xterm in Fedora and Debian VMs:

1. Select/highlight the desired text, thereby inserting it into the PRIMARY buffer.

2. Press <Ctrl + middle mouse button> in order to bring up a menu (I think it was the "VT Options" menu).

3. In this menu, select the option to copy text from the PRIMARY buffer to that VM's local clipboard.

4. Press <Ctrl + Shift + C> to copy text to the Qubes inter-VM clipboard and proceed as usual.

However, some time ago, step 2 suddenly stopped working, and I have no idea why. Pressing <Ctrl + middle mouse button> in xterm now does nothing, as far as I can tell. I've checked my trackpad/mouse settings, and everything seems fine and unchanged. I've tried pressing the left and right mouse buttons simultaneously instead, but nothing.

I know that I can probably create custom xterm settings that will allow me to copy text, but I'd still like to know whether there's a way to do it by default for cases in which the VM is uncustomized. Does anyone know if there is such a way?

I never used that, but here for the fedora-32 template it works.
I think you can override bindings inside the app via X resources, but my suspect is that the window manager "captures" the mouse or key event, so it does not arrive at the terminal any more.

I'm confused. You say it's working in the Fedora 32 template for you, yet you also say the key event is captured, so it's not arriving at the terminal anymore. How can it be working for you if the key event is being captured by the window manager?

You missed something: I' not the one who had the problem; I'm one who tried to help / explain.