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

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/2150
Reporter	zaytsev (@zyv)

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!

[mc-butler]

Changed by zaytsev (@zyv) on Apr 22, 2010 at 19:32 UTC (comment 1)

• Description edited
• Summary changed from Ctrl+Enter no longer copies selected file name to subshell in terminal on slang build to Ctrl+Enter doesn't copy selected file name to subshell in virtual terminal --without-x

[mc-butler]

Changed by andrew_b (@aborodin) on Apr 23, 2010 at 4:19 UTC (comment 2)

• Description edited
• Summary changed from Ctrl+Enter doesn't copy selected file name to subshell in virtual terminal --without-x to Ctrl+Enter doesn't copy selected file name to subshell in terminal emulator --without-x

[mc-butler]

Changed by ossi (@ossilator) on Apr 23, 2010 at 10:40 UTC

Replying to zaytsev (#2150):

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

[mc-butler]

Changed by zaytsev (@zyv) on Apr 23, 2010 at 12:13 UTC (comment 4)

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.

[mc-butler]

Changed by ossi (@ossilator) on Apr 23, 2010 at 15:17 UTC (comment 4.5)

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?

[mc-butler]

Changed by andrew_b (@aborodin) on Nov 3, 2011 at 9:22 UTC (comment 6)

• Milestone changed from 4.7 to Future Releases
• Branch state set to no branch

[zyv]

I think this issue might be resolved by #4769.