savannah: ctrl-\ hotlist key won't work under tty<i>

[ossi]

Original: ​http://savannah.gnu.org/bugs/?13729

Submitted by:	Oswald Buddenhagen <ossi>	Submitted on:	Mon 11 Jul 2005 04:00:03 PM UTC
Category:	Keyboard input	Severity:	3 - Normal
Status:	None	Privacy:	Public
Assigned to:	None	Open/Closed:	Open
Release:	current (CVS or snapshot)	Operating System:	GNU/Linux

Original submission:

in the linux console with a german keyboard layout, one is unable 
to get to the directory hotlist via ctrl-\.
in this layout, \ is altgr-ß (equivalent to ralt-= on an american 
keyboard). i suspect that mc refuses to activate the hotkey, 
because it finds ralt to be pressed.
this behavior is new in mc 4.6. 

Comment 1 by Oswald Buddenhagen <ossi> at Wed 21 Sep 2005 05:19:41 PM UTC:

i came up with this hack - it just makes the right alt key not be 
recognized as an alt key at all.
i have no idea how to fix it properly - one'd have to ask the 
keymap whether the ralt is part of the keycode or an additional 
modifier.
hard-coding exceptions activated after a keymap query might work, 
but is utterly ugly. well, the code already has similar hacks to 
accomodate all types of terminals ...

Comment 2 by Roland Eggner <robiol262> at Wed 29 Mar 2006 12:54:13 PM UTC:

I found a partial solution:
Ctrl+4 (left ctrl key + "4" on main part of keyboard)
brings mc hotlist, IF running in KDE console.
Works with my Notebook Toshiba Satellite 3000-514
and this versions: SuSE-8.2/KDE-3.1.1/mc-4.6.0-336,
and also Debian-etch/KDE-3.5.1/mc-4.6.1-1.
If it works on other machines too: should be added to help files.

More satisfactory would be an additional keybinding
- I suppose ctrl+H - that works with german
keyboard layout outside of X, too.
Until now, outside of X I must use menu entry,
have no keybinding for accessing the hotlist.
Only "add to hotlist" Ctrl-X H works.

[iNode]

Double for #195. Also blocked by #212.

[ossi]

relaying this to #212 isn't particularly nice. nobody wants to go through extensive configurations just to get the keyboard working in a particular application. am i expected to do that with every independent account i use mc on (4 as of now)?

both the linux console and x11 would actually allow querying the keyboard map, and for other terminals modifier querying isn't done in the first place anyway.

the much simpler approach would be making my hack an option. actually, FAR has exactly such an option ... not that i like the idea too much.

[iNode]

#212 allow to create common configuration schemes that will be nice for all (or about it) with lower costs. Oh, yes, it was described in #195. ;)

So for that issue, we will need hot-key in "classic" schema:
C-x prefix seems to be reasonable and consistent.
What do you think about "C-x ."?

[ossi]

this still doesn't solve the problem - it works around it. kinda backwards to have to learn new hotkeys to "fix" a regression, don't you think?
fwiw, i hate those c-x "escape sequences". i feel lucky that none of them is part of my regular workflow. as opposed to c-/.

[iNode]

in the linux console with a german keyboard layout, one is unable
to get to the directory hotlist via ctrl-\

Are you sure that is not terminfo issue?
Can you check it now with old version of mc
and acknowledge that is work in your current environment?

[ossi]

not every keyboard problem is a terminfo/termcap problem ... ;)

[iNode]

Yes, I know it.

But it's very old bug and we need to be sure that
we can check correctness of fix in current environment.

So, can you check it now with old version of mc
and acknowledge that is work in your current environment?

[iNode]

Ok, I can check it, ([] - keystroke):

setxkbmap -layout us,de
echo "[C+vC+\][space][change to de][C+v C+RAlt+-]" | od -c

and also in vim.

[iNode]

I checked it in my environment.

All work in mc builded with ncursesw, so it's slang bug.

Please, write bugreport to slang developers or your distro maintainers.

[ossi]

complete fail on your side. the ticket title clearly states that this is *not* about an x environment.
this is *solely* about the games mc plays with modifier keys and has *nothing* to do with slang, ncurses or the key translation of either. the proof is trivial: just "ssh localhost" to make mc think it's not running on a local linux console any more and thus skip trying to determine the modifier state.

[iNode]

It's also work in screen/ssh. Can you describe how to reproduce bug in mc builded with ncursesw?

[ossi]

alt-ctrl-f1
log in as root
loadkeys de-latin1
mc
ctrl-ralt-<key-2-left-to-backspace>

you can verify that without ctrl the backslash is entered.

[iNode]

Thanks for information. Now I can reproduce it.

As I thought the reason was an additional Alt modifier.
I think terminal should not send it because it's already
processed by keyboard translation table.

So it's workaround.
Please try patch below.

[iNode]

add hotkey M-C-\ for hotlist

[ossi]

Replying to iNode:

As I thought the reason was an additional Alt modifier.

impressive how you arrived at that conclusion - only 4 years after i wrote exactly that in the initial comment of the original report. ;-)

I think terminal should not send it because it's already
processed by keyboard translation table.

the terminal doesn't do anything. how about finally trying to understand the code, starting with my patch?

So it's workaround.

yes. it is an utter hack. how many of them do you want to add to make it work for everyone?

[iNode]

Replying to ossi:

Replying to iNode:

As I thought the reason was an additional Alt modifier.

impressive how you arrived at that conclusion - only 4 years after i wrote exactly that in the initial comment of the original report. ;-)

You wrote "i *suspect*" isn't it?

I think terminal should not send it because it's already
processed by keyboard translation table.

the terminal doesn't do anything.

So where we get \ key on german keytable?
Isn't Ralt-- should be replaced by "\" and not RAlt-\?
So what behaviour of terminal emulator should we wait
RAlt-- equal "\" as in Xorg with ncursesw or RAlt-- equall RAlt-\?
Or we just must add another more global workaround about this misbehaviour?

how about finally trying to understand the code, starting with my patch?

Yes I see your patch. But why you think this is right solution?

So it's workaround.

yes. it is an utter hack. how many of them do you want to add to make it work for everyone?

Yeah. For all mc lifetime just one your locale specific problem with bug report.
Can you write another use case?

[ossi]

Replying to iNode:

You wrote "i *suspect*" isn't it?

the second comment should have made fairly clear that the suspicion was right. ;-)

the terminal doesn't do anything.

So where we get \ key on german keytable? [...]

i can only re-iterate:

how about finally trying to understand the code, starting with my patch?

But why you think this is right solution?

it isn't. it's also a hack, though a more generic one. it's meant to illustrate the problem. the follow-up comment says that as well.

Yeah. For all mc lifetime just one your locale specific problem with bug report.

most non-US users simply accept it as given that some hotkeys don't work, more than other bugs. given the total number of bug reporters for mc, it isn't surprising that there are hardly any reports of it.

Can you write another use case?

this *will* come up again rather soon once you start adding more hotkeys. and when you define increasing numbers of "equivalence classes", you might well run into the situation that a workaround clashes with a native hotkey. or more likely that the workaround for one key on one keymap clashes with the workaround for another key on another keymap.

[iNode]

Replying to ossi:

Replying to iNode:

But why you think this is right solution?

it isn't. it's also a hack, though a more generic one. it's meant to illustrate the problem. the follow-up comment says that as well.

So it's just another workaround that can break something. We don't know how to handle it properly, but we should make it work for users.

most non-US users simply accept it as given that some hotkeys don't work, more than other bugs. given the total number of bug reporters for mc, it isn't surprising that there are hardly any reports of it.

Yeah, in example Meta-<any key in non latin locale> does not work as in latin locale (i.e. Meta-Ф not equal Meta-a). I know it cause I'm use it, but it's another case that should be handled by custom keymap. It's one of reasons of comment 2 that add dependency from #212.

this *will* come up again rather soon once you start adding more hotkeys. and when you define increasing numbers of "equivalence classes", you might well run into the situation that a workaround clashes with a native hotkey. or more likely that the workaround for one key on one keymap clashes with the workaround for another key on another keymap.

Yes and it's reason that make your patch inappropriate. It introduce big "equivalence class" and more chances to break something. For now my patch fix that ticket as simpliest *workaround*, any other advanced remappings (and especially locale specific) should be handled with #212 or another enchancements bases on #212.

And a little about custom keymaps:
You use custom locale specific keymap in Xorg, I'm use custom locale specific keymap in vim, emacs has it's workaroudns for this case and so on. It's normal solution in case of use non-standard keys. Any standard C-a...C-z handled properly in any application.

[ossi]

Yes and it's reason that make your patch inappropriate.
It introduce big "equivalence class" and more chances to break something.

that's plain wrong. it would be true if ralt was the only alt key, or even if people would expect it to do the same as lalt - which they don't (in germany and many other countries), as the key is named AltGr? and produces all kinds of "weird" characters. many other programs don't treat it as an alt key, either - in fact, none of the x applications i tried do (and xkbwatch shows lalt and ralt as two different modifiers, while lctrl and rctrl map to the same modifier, just like lshift and rshift do). in that sense, introducing the option to exclude ralt from the modifier magic is a perfectly valid approach to the problem with much less breakage potential than adding "eqivalance classes".

[angel_il]

try change hotkey for "quick_chdir_cmd" in ~/.mc/mc.keymap
CmdQuickChdir? in [main] section

[ossi]

which part exactly of what i wrote above did you not understand?

[slavazanko]

#212 don't helps in this case.

We need to learn how get keyboard map from text console (unix, bsd, cygwin, etc) and from terminal emulators. This not simple task, IMHO... not simple for me personally :) I'm totally do not know how do it.

[ossi]

well, yeah. lots of rtfm. :)

anyway, for starters, just implement the "treat right alt as alt" switch like FAR does. automating that for known terminal types would be level 2.

[sbrabec]

Ticket #287 provides a patch for Esc + key -> F-key emulation, if the key needs to use modifier.

[powerman]

I use Gentoo and xterm. Ctrl-backslash works ok in app-misc/mc-4.7.0_pre3 built with ncurses. But after today's upgrade to latest stable (in Gentoo) app-misc/mc-4.7.0.1, I found ctrl-backslash will kill mc (usual SIGQUIT, I suppose) built with ncurses but works ok if mc built with slang.

[andrew_b]

Replying to powerman:

But after today's upgrade to latest stable (in Gentoo) app-misc/mc-4.7.0.1, I found ctrl-backslash will kill mc (usual SIGQUIT, I suppose) built with ncurses but works ok if mc built with slang.

This was fixed in 4.7.0.3 (#1926, changeset:88d328a3f46876880673d51769c735fd5dca9c98). Please upgrade your MC.