Re: ctrl mappings don't work

[Oswald Buddenhagen <ossi kde org>]

On Sat, Jan 12, 2013 at 10:35:41AM +0000, frank wrote:
> >i'm not saying that it makes sense to remap ctrl-h/bs or ctrl-m/ret,
> >just that the offered explanation is bogus.
> 
> You started with [...]
> 
> "huh? slang/ncurses runs the tty in raw mode..."
> 
> in a thread that clearly and explicitely refers to a graphic terminal issue.
> 
what you are not getting is that this is utterly irrelevant.
slang/curses and therefore mc are pty clients under X, which makes this
equivalent to a "real" tty hosted directly by a virtual console.
consequently i'm talking about the raw mode of ttys/ptys (and NOT the
linux-specific KDGKBMODE ioctl), which you clearly didn't get despite my
not at all subtle hint.

> Finally there is no bogus explanation: keys intercepted by the
> terminal program cannot be redefined by MC or any other text mode
> application running under the terminal.
> 
the thing is that the keys are not "intercepted" or "handled" by the
terminal at all (that is what would happen in cooked tty mode, where the
tty would use these keys for editing functions of the internal buffer).
they are just mapped to the same ascii codes as other keys. this means
that if mc didn't have the meaning of those codes hard-wired somewhere,
it would be perfectly possible to re-bind them. of course this would be
of rather limited use, as then enter and backspace wouldn't work the
usual way, but that's not the point of my objection.

> If Marco wants to customise such keys, he will have to convince his
> rxvt-unicode first.
> 
dunno whether this is possible with rxvt, but with xterm he could
actually do that, at the cost of making other applications which expect
the traditional keybindings not doing what the user expects.

the really crazy idea would be linking mc to a terminal emulator
(creating a second specialized executable, xmc). this would solve a
whole bunch of problems:
a) arbitrary key mapping
b) clean x selection support (we already have x clipboard support via
   xclip, but that's only half the deal)
c) proper session management integration without jumping through hoops
   (see https://www.midnight-commander.org/ticket/24)
on a vt, a) can be implemented with a different backend, while b) and c)
are irrelevant.
when subcommands were called, the built-in terminal would host them
the usual way. the downside of that is that linux users typically think
they have a reason to use a particular terminal emulator (and in some
cases they actually have), so they wouldn't like mc forcing a choice on
them. consequently, a better solution would be standardized extended tty
escape sequences which allow tighter integration of text clients into
the windowing system despite the mediating tty emulator. i'm sure some
terminals already provide some of these features.