You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ctrl+Enter doesn't copy selected file name to subshell in terminal emulator --without-x #2150
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
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
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.
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?
Activity
mc-butler commentedon Apr 22, 2010
mc-butler commentedon Apr 23, 2010
mc-butler commentedon Apr 23, 2010
Replying to zaytsev (#2150):
from a terminal emulator, you mean.
no, there isn't, as you could have found out by:
wontfix/unfixable
mc-butler commentedon Apr 23, 2010
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 commentedon Apr 23, 2010
Replying to zaytsev:
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 commentedon Nov 3, 2011
zyv commentedon Sep 27, 2025
I think this issue might be resolved by #4769.