Skip to content

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

Open

Description

@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!

Activity

  1. mc-butler commented on Apr 22, 2010

    @mc-butler
    Author

    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
  2. mc-butler commented on Apr 23, 2010

    @mc-butler
    Author

    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
  3. mc-butler commented on Apr 23, 2010

    @mc-butler
    Author

    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

  4. mc-butler commented on Apr 23, 2010

    @mc-butler
    Author

    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.

  5. mc-butler commented on Apr 23, 2010

    @mc-butler
    Author

    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?

  6. mc-butler commented on Nov 3, 2011

    @mc-butler
    Author

    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
  7. added theissue type on Feb 27, 2025
  8. zyv commented on Sep 27, 2025

    @zyv
    Member

    I think this issue might be resolved by #4769.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: ttyInteraction with the terminal, screen librariesprio: lowMinor problem or easily worked around

    Type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions