ESC is sometimes dropped

[cqexbesd]

Contour Terminal version

0.3.10-master-2532adfe

Installer source

Github: source code cloned

Operating System

Arch Linux as of approx a week ago

Architecture

x86-64

Other Software

NVIM v0.8.2

Steps to reproduce

In a vi session, occasionally, a press of ESC is missed. It only happens occasionally and I don't know how to reliably trigger it. It may not be related to being in vi but of course that's when I would notice missing ESC.

With some debug tags on I see:

[2023-01-31 00:19:38.395865] [gui.input] Character press event received: Shift }
[2023-01-31 00:19:38.395922] [pty.output] Sending bytes: "}"
[2023-01-31 00:19:38.763825] [gui.input] Character press event received: None \e
[2023-01-31 00:19:39.267889] [pty.output] Sending bytes: "\eOA"
[2023-01-31 00:19:39.267916] [gui.input] key press: None UpArrow
[2023-01-31 00:19:39.467887] [pty.output] Sending bytes: "\eOC"
[2023-01-31 00:19:39.467911] [gui.input] key press: None RightArrow

So it looks like the ESC is missed being sent to the pty and from then on the input and output log messages are in reverse - i.e it sends my input before it receives it.

Expected Behavior

Every press to be sent

Actual Behavior

ESC was swallowed

Additional notes

No response

[christianparpart]

Good morning. I wonder if that is really a thing or if CSIu us the only way to fix this. 🤔

[cqexbesd]

I don't know if this helps but I just hit it in the shell with vt.input debugging on as well.

[2023-02-03 17:58:15.874057] [vt.input] Sending None UpArrow.
[2023-02-03 17:58:15.875447] [pty.output] Sending bytes: "\e[A"
[2023-02-03 17:58:15.875472] [gui.input] Key press event received: None UpArrow
[2023-02-03 17:58:16.145956] [gui.input] Character press event received: None \e
[2023-02-03 17:58:16.146003] [vt.input] Clearing selection.
[2023-02-03 17:58:16.388653] [gui.input] Input not handled for mods Shift key 0x1000020
[2023-02-03 17:58:16.602237] [gui.input] Character press event received: Shift $
[2023-02-03 17:58:16.602426] [pty.output] Sending bytes: "$"
[2023-02-03 17:58:17.665933] [gui.input] Character press event received: None \x08

Based on timing of log messages, is the ESC interpreted as "clearing selection" and not a regular key press? I'm not sure what the selection was - I wasn't aware of having anything selected at either time but maybe I mis-clicked at some point and had selected something? I will watch out for that in future to see if this is what is happening - I don't know if there is a debug flag to record such events?

[cqexbesd]

Just hit it again and there was certainly nothing selected that was visible, but there would have been something selected in the shell before I entered vi. If this is the cause then I shouldn't hit it again (assuming no more selection) whilst I am in vi - and that seems to be the case.

So that probably means this isn't a bug but a design flaw - in so far as the code is probably doing what was planned but the user experience seems sub par.

It seems like selecting with the mouse effectively puts the terminal into a special mode that you need to use ESC to get out of, but everything else works as normal. I think there should be no special mode and there can be a key combo to deselect if you want - which you could map to ESC if you really wanted to but is probably better using ctrl-shift-something like the other defaults.

[cqexbesd]

I have now removed the mapping for ESC to clear selection (which is the default) and I see no more lost ESCs so I think this was the problem. So I would say ESC shouldn't be mapped by default to anything, given it is captured even if the selected item has scrolled off long ago,

[christianparpart]

loool. Thanks @cqexbesd for the patience and finding out yourself. You would have made me going crazy trying to reproduce this (while not using the mouse) :-D

So I guess we can close it then?

And, this default key mapping of ESC clearing the selection in case something was selected, to me personally, still makes sense to keep as default.

Hm, wait, maybe I can generally improve on the Select mode in the config. 🤔

[cqexbesd]

I don't know the best solution but I think something should change - because it took me so long to work out what was going on and it was very annoying. Obviously it will only affect mouse users but I remember computers before mice and I think mice are great :-P

Probably the key confusing thing is that if the selected text is no longer on the screen, perhaps hidden by an editor, or just scrolled off, then there is no sign as to what ESC has done. If your workflow involves frequent copies though there will often be something selected and in previous terminal emulators it made no difference - mostly because the terminal was (probably) unaware of anything selected by mouse - the mouse did mouse things and the keyboard did text things. Contour merges these two worlds.