Ctrl+Enter doesn't copy selected file name to subshell in terminal emulator --without-x

[zaytsev]

Forwarded from Debian: ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375366

Summary:

1) Ctrl+Enter WORKS in raw console (Ctrl modifier detected via ioctl)

2) Ctrl+Enter WORKS in terminal --with-x (Ctrl modifier detected via mc_XQueryPointer)

3) Ctrl+Enter DOES NOT work in virtual terminal (in gnome-terminal, xterm, rxvt etc. Enter, Ctrl+Enter and Shift+Enter all return ^M).

The question is whether anything can be done about it? Is there any other way to detect modifiers when running from a VT?

Thanks!

[ossi]

Replying to zaytsev:

Is there any other way to detect modifiers when running from a VT?

from a terminal emulator, you mean.
no, there isn't, as you could have found out by:

• checking the escape sequences sent (hexdump -C, finish with 2x ctrl-d)
• looking through the mailing list archive
• looking through the bug database

wontfix/unfixable

[zaytsev]

Ossi, you are arrogant.

Initially, the problem was misdiagnosed and after it turned out to be related to --with-x I did check the sequences sent (see the updated description). However the fact that I looked through the bugzillas and checked the sequences does not imply that I couldn't have overlooked something.

For instance, in Konsole, Shift+Enter produces 1B 4F 4D instead of 0A as for all the other terminals and Meta+Enter usually produces 1B 0A in gnome-terminal and Konsole, but does C2 8D for xterm.

So there's no reason to believe à priori that there is no way to work around the Ctrl+Enter issue.

[ossi]

Replying to zaytsev:

So there's no reason to believe à priori that there is no way to work around the Ctrl+Enter issue.

oh, sorry - i misunderstood you: you do indeed mean running mc in a terminal emulator connected to a local x server, right? *of course* you can work around the issue. you just need to bypass two abstraction layers (hell, we do one, we can do two), and, oh, btw, you need to be root, because you are not the owner of the console. from here, it's just some trivial ioctls (the stuff mc does anyway when it runs in a vt; hopefully, the x server won't get confused).

if, otoh, you are interested in actually *solving* the issue (as in, make it work in every environment, including ssh sessions, remote x displays, etc.), you can try to get thomas dickey to make xterm send a distinct escape sequence for ctrl-enter and hope for a quick adoption of the precedent.
or you could go completely overboard and try to actually solve the issue in a generic way: introduce a modifier state reporting mode to xterm (like the mouse reporting mode). all modifier changes would be reported immediately. probably, all keys which create an escape sequence would send the unshifted sequence regardless of modifier state. and all printable characters would be prefixed by a sequence naming the modifiers which were "used up" in the generation of the character (so, e.g., ctrl-altgr-? on the german keyboard could be actually recognized as ctrl-\, not as ctrl-alt-\).
and as you are at it, you could extend the mouse reporting mode to report the mouse position even if no button is pressed. then, finally, a remote tty would be on par with bare pc hardware, a linux console or the x11 protocol (in that regard).
one can dream, right?