Unable to redefine tab key action #TAB

[Argon]

I searched like 5 hours for any way to redefine default action assigned to TAB key (to not switch between panels so to be able to use it for autocompletion). I looked over all mc.keymap config files, but it doesnt contain such setting. I checked man mc, internal mc help utility and this website wiki. No information at all. Is it possible at least?

This issue adressed to problem with TAB key action rebinding (it needs to be possible to trigger autocompletion on TAB key) AND providing any information if it is:
a) possible (so, how?);
b) not possible (this should be covered in man pages, help topics and wiki as well, as special remark)

[Argon]

Also, similar qustions asked a couple of times in stackexchange/overflow and discussed a lot of times in different help forums, so many people stuck on that. This problem repels many new users out of using MC.

[andrew_b]

Branch: 3672_bind_tab
changeset:19f02a031290229a810154497d72b75f86524917

[mooffie]

I haven't tested the patch, but the code looks fine.

(I guess you've investigated the possibility of putting the TAB key on the dialog_map keymap and deemed it problematic for some reason.)

Here's an idea for improvement (though I haven't thought about it much; it might be flawed):

If CK_ChangePanel returned MSG_NOT_HANDLED when there's only one panel shown (as in the case of the "Long file list" listing mode), then the TAB will be sent next the to command-line (see ​sequence diagram). This would let users use TAB to switch panels normally, but to auto-complete when only one panel is shown.

Other random notes, which you can ignore:

• The "ChangePanel" command introduced here is half of solving #3591.

• BTW, if the user wants TAB to ChangePanel only if the cmdline is empty, and Complete otherwise, then #3664 would let him do this with:

# !! untested !!
[main:empty-cmdline]
ChangePanel = tab
[main]
ChangePanel =
[input]
Complete = tab; alt-tab

[zaytsev]

OT: @mooffie did you generate this nice diagram programmatically, or you drew it yourself manually? Just curious.

[mooffie]

Replying to zaytsev:

OT: @mooffie did you generate this nice diagram programmatically, or you drew it yourself manually? Just curious.

It was generated programmatically. ​Here, where I introduced this diagram, I linked to its source script.

A little history:

Many years ago I used sequence diagrams to help me study some system. The tool I used for drawing was ​sdedit, which draws the diagram for you based on a textual description you give it. Unfortunately, its language is horrible for humans (IMHO), so I ended up writing a ​Ruby "DSL" that, given a less horrible syntax, produces input for sdedit. That's how I generated that diagram. I'd imagine that nowadays there exist nicer tools/languages for doing this.

[zaytsev]

Ah, I see; thank you for the clarification. In that case, it's not programmatic in a sense that you have to write the DSL yourself, instead of some source code analyzer. That's what I was interested in...

[Argon]

Replying to mooffie:

(I guess you've investigated the possibility of putting the TAB key on the dialog_map keymap and deemed it problematic for some reason.)

Yes, I tried in many ways (using mc.keymap in user's home dir and also global mc.keymap file in /etc/mc). My settings just ignored/overwritten.

Here's an idea for improvement (though I haven't thought about it much; it might be flawed):

If CK_ChangePanel returned MSG_NOT_HANDLED when there's only one panel shown (as in the case of the "Long file list" listing mode), then the TAB will be sent next the to command-line (see ​sequence diagram). This would let users use TAB to switch panels normally, but to auto-complete when only one panel is shown.

I like this idea as last resort case, I don't think this is the best idea because one key must do same action no matter how many pannels in screen, thats a good practice for any UI. Users will get used to press TAB for some action being in one panel view mode and will be confused trying to make same action in another view.

• BTW, if the user wants TAB to ChangePanel only if the cmdline is empty, and Complete otherwise <...>

The bad thing here is that you will be unable to switch if command line is not empty (like in case if you want to put to cmd string some file name from other panel).

Generally, it should be possibly to redefine TAB for autocomplete action and TAB+something for panel switch. Alternatively it also will be useful to make some checkbox for inverting ESC-TAB (M-TAB) with TAB (so ESC-TAB will switch and TAB will autocomplete) - it is easy for configuration and hotkeys will act evenly in any cases. May be last solution is even better than making option for arbitrary redefinition, at least I use panel switching quite rarely and wont be annoyed to press two keys to switch (like now when I annoyed of having to press two key for autocompletion).

[andrew_b]

Merged to master: [8bf560cb8edb62edb90f70ed701858a686b53dde].

[Argon]

Replying to andrew_b:
Nice, thanks! I guess using apt-get for update wont get it because it is not released yet.
What is a proper way to get this patch? Or better to wait until new version release?

[andrew_b]

Replying to Argon:

What is a proper way to get this patch?

You can try a one of nightly builds.

Or better to wait until new version release?

The next release will be after a long time (several months).

[cri]

Hi, please note that

[input]
...
Complete = tab

will autocomplete on the command line, but not on text fields in dialog windows (e.g. copy file, etc).

Is it possible to have Complete = tab also for dialog windows? I tried putting it in the [dialog] section of my mc.keymap file but it doesn't work.
Of course if this is implemented, we should also need to define another key to navigate through dialog fields (instead of tab).

So far, I'm using this suboptimal workaround:

[input]
...
Complete = tab ; alt-tab

... so I get tab completion on the command line, and old-style esc-tab completion on text dialog fields.

[andrew_b]

Replying to cri:

will autocomplete on the command line, but not on text fields in dialog windows (e.g. copy file, etc).

File name completion via alt (or esc)-tab works fine for me in the copy/move dialog, in the "Save as" dialog in mcedit, etc.

Is it possible to have Complete = tab also for dialog windows?

Complete what? Each input line has its own specific stuff: file names, words, etc. For example, the file name completion for "Content" field of "Find file" dialog in pointless.

[cri]

Replying to andrew_b:

File name completion via alt (or esc)-tab works fine for me in the copy/move dialog, in the "Save as" dialog in mcedit, etc.

Indeed, my message was about completion via tab (after setting Complete = tab), not via alt/esc-tab.

Complete what? Each input line has its own specific stuff: file names, words, etc.

Nothing new, I meant to have the same completions that are available now on each input line, only using tab instead of alt/esc-tab.

(and to be able to define another key, instead of tab, to move across fields)

[andrew_b]

Replying to cri:

Indeed, my message was about completion via tab (after setting Complete = tab), not via alt/esc-tab.

Unfortunately, Tab and Shift-Tab keys are hardcoded to switch current widget in a dialog.

[cri]

Replying to andrew_b:

Unfortunately, Tab and Shift-Tab keys are hardcoded to switch current widget in a dialog.

Well I guess the problem is "how hard" they are hard-coded :)

...but I can't judge that, or even come up with patches, so I'll just repeat my suggestion: now that we are able to redefine tab for completion on the command line, it would be really nice to have the same behavior also on widget text fields.

[cri]

Reopening, because the support for redefining tab action introduced with this ticket got broken in mc 4.8.26.

More specifically, in ~/.config/mc/mc.keymap:

• [main] section: the ChangePanel setting seems to ignore any value, whatever value I set, the tab key has always the effect of changing panels.
• [input] section: the Complete setting still works for values different from tab (e.g. alt-tab, or shift-tab), but setting tab here has no effect anymore

So the tab key seems to be hardwired again to only change panels, it's not possible anymore to use it for command completion.

Looking at https://midnight-commander.org/wiki/NEWS-4.8.26 initially I thought that the fix in #4107 could have introduced the regression, but I tried rebuilding 4.8.26 without that fix and the support is still broken.

The other tab-related fix mentioned in NEWS-4.8.26 is #2269; so maybe the regression was introduced by that fix, or/and by some other changes occurred between 4.8.25 (which works OK) and 4.8.26. Any help?

Another (maybe related?) minor issue: assigning ChangePanel = ctrl-tab has never worked for me (only shift-tab worked); it would be nice to be able to use ctrl-tab to change panels (i.e. the same keys used to change tabs in web browser windows). Maybe this can be fixed while debugging the main problem described above? Otherwise I'll open a different ticket for this.

[andrew_b]

Replying to cri:

• [main] section: the ChangePanel setting seems to ignore any value, whatever value I set, the tab key has always the effect of changing panels.

[main] was renamed to [filemanager]: changeset:1869dffd140c7d5454c3aceaba80ec93ed438a06. Sorry, this change is missed in NEWS-4.8.26.

[cri]

Replying to andrew_b:

[main] was renamed to [filemanager]: changeset:1869dffd140c7d5454c3aceaba80ec93ed438a06. Sorry, this change is missed in NEWS-4.8.26.

Ouch, I missed that too when diffing old/new config files. Thanks!

Re the ctrl-tab problem I mentioned above, actually it's just a small quirk: ChangePanel = ctrl-tab for switching panels usually works fine, with one exception: if I run mc after becoming root via su -, it stops working: ctrl-tab behaves just like tab.

Some more tests I did:

• Using a non X virtual console is OK, so it must be related to the X server
• Running X as root is OK
• Using su (instead of su -) is OK
• Using another shell instead of bash: same behaviour, so it's not a bash specific problem
• Using another xterminal emulator instead of xterm: same behaviour, so it's not a xterm problem

I'm not even sure this is a midnight commander bug (so I guess you can close this ticket): a quick googling reveals that ctrl-tab is often problematic in X for some applications and/or terminal emulators, and there are all sorts of suggested fixes that involve hacking ~./Xresources, xmodmap etc to get ctrl-tab working properly, but I eventually gave up.

I'm using the following workaround instead: ChangePanel = ctrl-tab; shift-tab, so when ctrl-tab doesn't work, I can use shift-tab.

[andrew_b]

Ok.