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. _______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel
