`learn keys` dialog has rough edges

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/4491
Reporter	ossi (@ossilator)

i managed to map enter to '/', with the expected consequences for usability.

this obviously shouldn't be even possible to start with.

but that experience shows another thing: the ui offers no (obvious) way to unmap keys.

it's also woefully incomplete, with no way to map the various modified keys.

so i wonder whether the dialog as it currently exists even makes sense. maybe it would be better to replace it with a text editor for the config file's mapping section for the given terminal, or even just a hint what to do.

the alternative would be beefing it up significantly, using a hierarchy or a scrollable view to have enough space for everything.

[GfEW]

i managed to map enter to '/', with the expected consequences for usability.

this obviously shouldn't be even possible to start with.

I'd agree that some useless or dangerous key mappings can be set up, but mc was never meant to be foolproof. Instead, it rightfully focuses on serving as a consistent, highly efficient file management toolbox for people who know enough of what they're doing to get along at the command line.

One of mc's key points is to bring the same known and proven range of tools to a wide range of possible environments - tools that either work out of the box even in exotic scenarios or crippled systems (e. g. embedded, routers, over flimsy remote access lanes etc.), or can be easily adjusted as needed to work. The learn keys dialog plays an important role in the latter case.

Therefore,

whether the dialog as it currently exists even makes sense

is, in my view, out of question, even if

the ui offers no (obvious) way to unmap keys

and

[there is] no way to map the various modified keys

Of course, lifting these two limitations would be very helpful, and it's great to see #5029 being addressed.

maybe it would be better to replace it with a text editor for the config file's mapping section for the given terminal

Please don't.

For one thing, mc's *.keymap files can be rather lengthy on their own; they are kept separate from ini for good.

But much more importantly, forcing affected users to

1. learn how to find out the exact given terminal, and specify it correctly
2. learn how to find out the input sequence sent by a specific key
3. learn the intricacies of mc's keymap storage
4. then, for each key,
   4.1. manually find out the respective input sequence sent by that key
   4.2. manually edit the active map until it acts as intended

just for the sake of mc doing its job, would add unreasonable amounts of extra effort to the key mapping procedure, with no benefit over the current state of affairs.

UX paradigm wise, mc excels at dissolving the notorious choice between "automated/smart" and "full manual control" exactly by providing midway interfaces like good old "learn keys" dialog that bridge the gap.

[egmontkob]

just for the sake of mc doing its job

or

just for the sake of mc working around bugs of the underlying platform

Which one is it? It's highly subjective I guess, depending on how you look at these things.

[GfEW]

just for the sake of mc doing its job

or

just for the sake of mc working around bugs of the underlying platform

Which one is it? It's highly subjective I guess, depending on how you look at these things.

I understand the aversion towards workarounds, based on the grounds that they tend to consume extra dev hours and sometimes even contribute to the worked-around bugs being forgotten rather than resolved.

I think nonetheless that, despite its popularity on a wide range of systems, mc is not in a position where it could enforce platform level bugfixes by turning purist.

(To that aim, direct reports very likely bring about better chances, and less damage to your own project, than crippling mc's usability on some platforms because "you are right".)

To be clear, that's not to say mc should do the job of platform devs. However to some extent, workarounds are part of the business - the more platform independent you go, the more likely there are concessions to be made.

That holds all the more if your "workaround" is as lightweight and versatile as mc's "Learn keys" dialog, able to address an entire class of bugs in a large number of systems at once.

[zyv]

just for the sake of mc doing its job

I think nonetheless that, despite its popularity on a wide range of systems, mc is not in a position where it could enforce platform level bugfixes by turning purist.

(To that aim, direct reports very likely bring about better chances, and less damage to your own project, than crippling mc's usability on some platforms because "you are right".)

Removing a confusing and probably not very much used configuration dialog instead of putting much more work into making it better (which the author doesn't seem to be interested in) has nothing to do with "turning purist" or "trying to enforce platform bug fixes". How about tuning down your rhetoric devices a couple of notches? I saw you accusing others of the same vice.

Even if this dialog is removed, the underlying configuration possibilities would remain. I personally found this dialog extremely confusing and badly documented when I tried to use it, so I actually work with the configuration directly.

The suggested "improvements" to add modifier support without rethinking and improving the dialog itself will not make it any better. I actually also see problems from yet a different angle. Some modifiers are indistinguishable in certain configurations. What happens then?

Too bad that we don't have intrusive analytics wired in to abuse and spy on our users like it is commonly accepted to be the ethical thing to do these days. Otherwise, we would have some real statistics on who uses it and how. If it's just you and the author (which was my impression in the last decades, judging from incoming issues), then I would claim that no amount of valid argument justifies its continued existence in the first place, even if this will make you two unhappy...

[egmontkob]

Another rough edge:

(At least in xterm-compatible terminals) In Application Cursor Keys mode (tput smkx) which mc uses, keypad / * - + still generate the single ASCII byte if NumLock is On. Only if NumLock is Off do they generate some escape sequences, with the modifiers encoded.

This is something the Learn keys dialog doesn't say a word about; thereby, for those who keep toggling NumLock, making this dialog randomly learn these keys or not.

Also, with this combination (Application Cursor Keys mode + NumLock off), keypad Enter also generates an escape sequence. Why don't we allow to teach that to mc? I expect that if / * - + don't work out of the box then neither does Enter.

[mc-worker]

Why don't we allow to teach that to mc?

#3168

[GfEW]

Tones and tunes

Thank you, @zyv, for your moderating comment. I have no intention whatsoever to contribute to the heat (actually the opposite), and am very sorry if that's been the case here.

Some parts of my previous comment were actually in response to "absolutely not something that mc should try to work around. it's something that should be fixed by fixing and adding terminfo entries and fixing terminals" and ff., rather than to @egmontkob's simple, relatable question here, and out of place.

The regret weighs even more because if reading my words becomes harsh, nuanced understanding quickly deteriorates.

Something along those lines preceded my own decision to comment on the dense language found in #5027: When I read through the thread, I thoroughly misunderstood @egmontkob's criticism of @ilia-maslakov's current draft (concerning e. g. doubly activated modifiers, or Shift+F11..F20) for no factual reason. Reading it again with stronger efforts to dim down the rhetoric reveals sufficient clarity.

which the author doesn't seem to be interested in

I wonder if @ilia-maslakov has really suddenly stopped being interested in completing his work (by removing those redundancies etc.), or is rather having similar difficulties at sorting the wheat from the chaff.

I've been thinking for a long time "Learn keys deserves modifier toggles!" (independently of #4491 and #5027, which I've learned about yesterday), and seeing @ilia-maslakov take it on was good news in that regard. But when his draft got criticized in the way and tone it got, I felt that something was going awry.

Usability - by whom?

Adding to the above, all feedback on the PR I'd seen so far was given by the three of you (@egmontkob, @ossilator, @zyv), who regard the "Learn keys" dialog as:

• "I wouldn't mind dropping this dialog, and instead documenting in mc how to figure out the escape sequences (including enabling smkx) and how to add them to mc's config"
• "the idea to drop the learn keys functionality and rely on accurate terminfo was also floated (mostly by me, it seems)"
• "I would really very much like to get [Kitty] merged and remove all this learn keys business / relying on terminfo as you suggest instead of keeping flogging this dead modifier horse"

which suggests to me you don't see much value in it (with or without modifier toggles) when compared to the manual key sequence map setup procedure you're equally comfortable with.

That's understandable, given your sheer depth of expertise, and to a (much) lower degree, I could chime in, since I've also grown comfortable with manually editing (most of) mc's configuration. (1)

However, all that tells little about the experience of the majority of users, as all participants of this conversation are very likely in the top decile of the userbase with regard to mc config adeptness. (2)

Rationale

I really wish that mc may continue to be as beginner-friendly, self-explanatory and multi-faceted as it has been to me - that's at first sight, but also throughout the years of adjusting it to given needs and discovering more and more of its advanced features and internals.

mc ideally does not require users to pursue a specific learning curve but allow smooth progress (to the extent they wish) by offering smaller intermediate steps, e. g.

• (a) "accept whatever mc's terminal recognition logic configures for you"
• (b) "discover and use Learn keys"
• (c) "map your key input sequences by hand in the config".

(1)

Still, "Learn keys" provides a MUCH faster way to get things straight if you e. g. frequently set up mc on varying embedded devices, or your hardware repository is generally more fluid.

(2)

More accurately, the three of you are most likely in the top 0.0001% (assuming a userbase of at least a few million).

[egmontkob]

which suggests to me you don't see much value in it (with or without modifier toggles) when compared to the manual key sequence map setup procedure you're equally comfortable with.

I am absolutely not familiar with the manual setting of those keys. I could go figure it out if I waned or needed.

I think the point you're entirely missing is that all this "Learn keys" dialog is (or at least really should be) needed for an extremely tiny fraction of our users. The keys should just work. I am using a standard Linux distribution with one of the standard popular nice graphical terminals, and the keys I need just work fine out of the box. (Well, except Shift+Fn with ncurses, but that's our bug and our task as developers to fix in the binary (not via config options or the Learn keys dialog).)

We have to balance between making mc as user-friendly as reasonable, vs. maintenance and developer cost; in this case in the form of reviewing / guiding a change whose aims is for a tiny fraction of the user base to improve things, but unfortunately makes it worse in some notable aspects.

It's inevitable to make some underlying fixes / improvements for 4.9. At least changing whatever breaks compatibility (e.g. rename f11 to shift-f1 etc. in the config files), but along with that I'd also want to fully eliminate using the F11..F20 notation anywhere from mc (including its UI, documentation), and also fix the off-by-two with the shifted function keys in ncurses.

As I'm arguing in #5027, this techically cannot happen after Ilia's changes. It needs to happen either before them, or at the same time.

We'll need to hear from Ilia what he is planning to do. If he's willing to do all this preparation work, I'd be more than happy to relax and let him do it. If he'd rather not do these underlying fixes, I'll be happy to work on them, but eventually he'll need to update his work on top of that.

We've gathered quite a few problems with the Learn keys dialog, and unfortunately I'm not too keen on working on them. I have no firm opinion whether to keep that dialog or drop it, and I'm not going to be the one making the decision. But I don't feel like fixing / updating its shortcomings (apart from trivial labeling changes). If someone updates it and addresses the problems, bearing in mind the direction of the underlying changes that are about to happen and taking our feedback into account, I believe the feature has a better chance of surviving. Should Ilia lose motivation and no one else step up either, I'd guess it's more likely that we'll drop that feature. But I can't tell for sure.

[GfEW]

which suggests to me you don't see much value in it (with or without modifier toggles) when compared to the manual key sequence map setup procedure you're equally comfortable with.

I am absolutely not familiar with the manual setting of those keys. I could go figure it out if I waned or needed.

What I mean isn't necessarily that each of you adjusts key sequence maps on a daily basis (which BTW I've gotten into, creating a more comprehensive emacs keymap that works without function keys), but you're fundamentally familiar and comfortable with the kind of work and steps to get there.

If you, an eloquent C developer, need to "go and figure it out", that's a very different scale of an hurdle (if any at all) than an inexperienced user being forced to try their best at that, should the mc team have decided to reduce alternative routes to none.

The "Learn keys" dialog makes little difference between you and that user, whilst even just grasping the concept of a key sequence, and how to determine, then "copy" and finally specify to mc, the sequences sent by specific key combinations, can be a huge deal. You can urge inexperienced users into throwing copy-pasted stuff at the shell far beyond their comprehension, but you cannot force them to learn what they're doing (let alone at the very moment they just want to use THAT key) - and that's worse, not better, than having them use a mapping dialog with some rough edges. The path without the latter would be especially awkward if they've never really used a CLI before - which mc otherwise allows to happen much later in the learning game.

One of mc's unique selling points is that it serves such a broad spectrum of abilities and systems/devices.

Ability wise, it serves

• shell literates as an highly efficient CLI enhancement
• beginners as a supportive, accessible TUI file manager/editor/viewer/... allowing them to accommodate themselves to the terminal little by little while doing actual work
• and everyone in between,

for good.

I think the point you're entirely missing is that all this "Learn keys" dialog is (or at least really should be) needed for an extremely tiny fraction of our users. The keys should just work.

I am aware of my (and supposedly Ilia's) cases sounding exotic to you, or yours being more narrowed down to the most familiar, popular scenarios, but there's really a bunch of separate questions involved:

1. Systems/devices: Do we agree that the "Learn keys" dialog should, ideally, not be necessary because all bound (or sensibly bindable) key combinations should just work on all systems?
   --> I do.
2. Systems/devices: Do we agree that it's impractical to get every terminal work correctly, so "Learn keys" is never needed? (And this boils down to how narrow or wide a range of terminal scenarios mc supports.)
   --> I do.
3. Systems/devices: Do we agree that user frustration about dysfunctional keys (see 2.) in mc with no easy way to learn them wouldn't translate well to the underlying terminal bugs getting fixed?
   --> I do.
4. Systems/devices: Do we agree that mc proves extremely useful on a large variety of devices - from DSL or mesh routers, over miniature computers, re-used android devices, NAS or multimedia boxes, to the likes of EeePCs (still in use!), other more or less legacy hardware running whichever systems they can, up to the newest, full-blown gaming laptop and beyond -, and that around the world, only a minority of users has access to up-to-date hardware that runs the latest Linux standard distro with ease?
   --> I tend to think so, hence don't quite concur with "tiny fraction".
5. Abilities: Do we agree that feedback intensity, measured e. g. in the frequency of issues filed, is heavily biased towards the concerns of users already tech-savvy enough to file an issue in the first place (think of your ma or grandpa - many interested beginners ain't even youngsters), and therefore, beginner-level, "trivial" issues should be weighed with a much greater affected users / complaining users ratio in mind, to at least very roughly make up for the bias?
   --> I do. This is where the argument (in my own words) "Learn keys is stale/niche because virtually noone talks about it" fails on me.

I am using a standard Linux distribution with one of the standard popular nice graphical terminals, and the keys I need just work fine out of the box. (Well, except Shift+Fn with ncurses, but that's our bug and our task as developers to fix in the binary (not via config options or the Learn keys dialog).)

Agreed. There are a few key input issues remaining with full-on mainstream scenarios, but they are at the fringe of the reasons why I (and supposedly, Ilia) think that "Learn keys" should be improved.

We have to balance between making mc as user-friendly as reasonable, vs. maintenance and developer cost

Generally agreed, obviously. Removing "Learn keys" specifically appears as an unfavorable choice to me, because (as already stated) it addresses not one or two bugs, but

an entire class of bugs in a large number of systems at once

• without even the need for you to have them available and tested!

in this case in the form of reviewing / guiding a change whose aims is for a tiny fraction of the user base to improve things, but unfortunately makes it worse in some notable aspects.

Could you name some notable aspects where a properly designed, modifier-enhanced "Learn keys" dialog would make it worse? - Is it about the flaws of Ilia's current draft (that would AFAICT only affect the dialog itself), or about the core proposal to allow users to teach mc keys with selected modifiers simply by typing them into the "Learn keys" dialog?

It's inevitable to make some underlying fixes / improvements for 4.9. At least changing whatever breaks compatibility (e.g. rename f11 to shift-f1 etc. in the config files), but along with that I'd also want to fully eliminate using the F11..F20 notation anywhere from mc (including its UI, documentation), and also fix the off-by-two with the shifted function keys in ncurses.

Makes sense, looking forward to those changes.

As I'm arguing in #5027, this techically cannot happen after Ilia's changes. It needs to happen either before them, or at the same time.

Yep, I've read the entire thread.

We'll need to hear from Ilia what he is planning to do.
[...]
We've gathered quite a few problems with the Learn keys dialog, and unfortunately I'm not too keen on working on them.

Let's hope he doesn't feel discouraged, and continues to improve and polish #5029 to a state that can be merged.

I have no firm opinion whether to keep that dialog or drop it, and I'm not going to be the one making the decision. But I don't feel like fixing / updating its shortcomings (apart from trivial labeling changes). If someone updates it and addresses the problems, bearing in mind the direction of the underlying changes that are about to happen and taking our feedback into account, I believe the feature has a better chance of surviving. Should Ilia lose motivation and no one else step up either, I'd guess it's more likely that we'll drop that feature. But I can't tell for sure.

Thank you for the explanation, and for your considerations further above.

p. s. Hope this post marks peak length. I'm not generally that wordy, but there's a lot of context intermingled here that seems crucial to establish common grounds, as far as possible.

[egmontkob]

What I mean isn't necessarily that each of you adjusts key sequence maps on a daily basis (which BTW I've gotten into, creating a more comprehensive emacs keymap that works without function keys),

You are now confusing "Learn keys" (fixing bugs of the underlying layers, letting mc know e.g. "the unknown event you saw now was actually a Shift+F6 keypress") with "Configure keys" (setting up mc to your preference to execute on Shift+F6 whatever action you want to execute – something we don't have now).

In a previous comment I argued that even if mc implemented both features (which it currently doesn't), it would probably still be better to keep them as two different layers rather than combining them into one.

I don't think it helps your cause of protecting the "Learn keys" feature if you argue that you do often use "Configure keys" in another piece of software. It just gives me the feeling (on top of multiple communication misunderstandings in a very short time) that you don't necessarily see clearly what we're talking about.

---

Your bullet points: 1. I agree. 2. I agree that not all terminals work fully out of the box, but I disagree that a graphical workaround is absolutely necessary. 3. I don't understand the question.

4. on a large variety of devices - from DSL or mesh routers [...] don't quite concur with "tiny fraction"

You can't just make a list of possible setups where mc is used and take them all with the same weight!

And who on Earth stops anyone who is creating an operating systems for these computers to do this in a decent quality, with terminfo accurately describing the behavior of whichever terminal they ship?

By the way, do you have concrete examples where things don't work out of the box, but can be fixed via Learn keys? (I would really like to understand the underlying causes, although I probably won't be able to get my hands on such systems.)

only a minority of users has access to up-to-date hardware that runs the latest Linux standard distro with ease?

I presume that very few people pair up an ancient base system with the newest mc. Most people use whatever their vendor (distribution) ships. Those who use a 15 year old OS (maybe offline, maybe risking to be vulnerable because it's no longer patched) almost certainly use the 15 year old mc shipped with that and won't upgrade. Pairing up mc 4.9 with 15 year old systems is hardly a valid use case we should be worried about.

I don't have data, probably you don't have either, maybe we can look up some generic stuff, but I would guess that the vast majority of the users use some OS younger than about 5-10 years. Surely there's a long tail, for a variety of reasons (e.g. poor regions happy to use older computers as long as they work). It doesn't matter where you reside in up-to-dateness. Whenever you'll have an OS that comes with mc 4.9 (to be released in 2026), you'll have the rest of the OS from around 2026, too.

Terminals and terminfo have improved a lot over the last decades. If you are aware of systems that still have a broken terminal or terminfo, please file them a bug and help them fix that ASAP.

Could you name some notable aspects where a properly designed, modifier-enhanced "Learn keys" dialog would make it worse? - Is it about the flaws of Ilia's current draft

Yes. I was talking about its current state, not a hypothetical (yet to be developed) fixed version.

Hope this post marks peak length

I think we've discussed this enough. I don't think writing any more long (or short) comments convincing us why this feature should stay will change the outcome. What could hopefully change the outcome in your favor is to contribute a high quality upgrade of that dialog, bearing in mind the overall direction and underlying changes we want to go (or even contributing those underlying changes, since, as I've argued, they're a prerequisite), and addressing the other various issues raised here. (Well, get a buy-in first from those who currently wish to drop this feature, to make sure the work is not wasted.)

[zyv]

(Well, get a buy-in first from those who currently wish to drop this feature, to make sure the work is not wasted.)

I'm not against a high-quality upgrade, I just don't see it happening (and certainly not doing it myself). Unfortunately, we mostly get longreads and when you ask for code it's "sorry, I can't do it" - and yet time for writing instead of studying how to code is certainly available.

[GfEW]

@egmontkob

argue that you do often use "Configure keys" in another piece of software.

Huh? We're talking mc here. The more comprehensive emacs keymap I'm working on improves mc.emacs.keymap, mainly in the [editor] and [filemanager] sections and their :xmaps.

It just gives me the feeling (on top of multiple communication misunderstandings in a very short time) that you don't necessarily see clearly what we're talking about.

My grasp of the technicalities may superficial and terminology fuzzy, but I am able to tell apart

• (1) 97 press, 105 press, 105 release, 97 release
• (2) ^[[1;5D
• (3) ctrl-left (*)
• (4) WordLeft

Clarity would improve with exact terms referring to each of them, and to mappings (1)->(2), (2)->(3), (3)->(4).
(Am I right the latter two are "learn" and "configure", in mc parlance? Please note, those generic terms are not inherently evident to non-programmers. I'm willing to use "your language" as soon as I know.)

(1) can be obtained from showkey -k; (2) from pressing Ctrl+q ("quoted-insert"), then modifiers+key; (3) and (4) from existing *.keymap files. I have NOT manually handled levels (1) or (2) in any mc config yet.

Personally, I'd get along (mostly) without using "Learn keys" because I've learned to create (3)->(4) keymaps that don't depend on frequently dysfunctional/unavailable keys. (**) Taking that hurdle (or worse, manually configuring '^[[1;5D'->'ctrl-left' level maps) where keys do fail, just shouldn't be introduced to mc users as a requirement.

If you are aware of systems that still have a broken terminal or terminfo, please file them a bug and help them fix that ASAP

That's even farther beyond a plain user's reach! If you have no idea of terminfo (***), how should you know when terminfo is the culprit, then diagnose and help "them" fix it? (If "they" even exist and care, that is.)

 disagree that a graphical workaround is absolutely necessary

It isn't. We're talking about sensible and helpful here.

very few people pair up an ancient base system with the newest mc

Good point! That does reduce the potential blind spot.

You can't just make a list of possible setups where mc is used and take them all with the same weight!

No same weight implied, but please bear existing variety in mind.

I've used mc on all of those categories, except NAS boxes and gaming laptops. Will try to recollect some of them to answer your question for

concrete examples where things don't work out of the box, but can be fixed via Learn keys?

Lastly:

I don't think writing any more long (or short) comments convincing us why this feature should stay will change the outcome.

Point taken. I've added the above for better comprehension.

(*) ctrl-left is one of the shortcuts I don't get working in mcedit on termux, even though it works there in readline. "Learn keys" with modifier toggles would supposedly solve this in an instant.

(**) Unlike (1)/(2), levels (3)/(4) are portable (modulo line breaks?), i. e. the keymap can be used anywhere.

(***) I, for one, might still learn all necessary stuff to get a platform bug reported (I've jumped through similar hoops in the past).
But anecdotal fixes cannot substitute the generic resilience provided by "Learn keys" as a pragmatic, accessible remedy

[GfEW]

@zyv

I'm not against a high-quality upgrade, I just don't see it happening (and certainly not doing it myself). Unfortunately, we mostly get longreads and when you ask for code it's "sorry, I can't do it" - and yet time for writing instead of studying how to code is certainly available.

Alas, that's a correct description of my case, and I'm sorry about that.

Lacking a viable improvement path on the coding side (I've tried hard and ran aground hard, too often, esp. with C) with no prospect whatsoever of creating something like Ilia has so far, let alone an high-quality upgrade, I'm contributing what I'm better able to: mainly UI/UX design considerations, filing bugs, or giving voice to perspectives of stakeholders underrepresented (if not absent) in the social filter bubble that github really is. Those perspectives are often not identical with mine, although the removal of "Learn keys" would also moderately affect my own reliance on ˋmcˋ.

I take the reflection of dysbalance in your comment as a reminder that ˋmcˋ is in dire need of developer capacity much more than of discussions, suggestions, or feedback from non-developers. Will focus on keeping comments more concise than in this thread, to not further aggravate that dysbalance.