Unfortunately, this approach benefits the Fields Management screen only. As such, it might disadvantage users when it comes to other screens needing horizontal or vertical support.
A more universal solution is already available in top that applies to the Fields Management screen, both Inspect screens, the Color Mapping screen (next release) and the main top display (including line oriented input).
Just use the Meta/Alt key with any of 'h', 'j', 'k' or 'l'.
@warnerjc I tried this solution in several terminal emulators, and found out that it has some issues. These combinations work well in framebuffer console, but in libvte-based emulators Alt is sometimes treated as Escape, and in xterm they do not work at all, only cause a refresh.
Also, the different behaviour of Left/Right arrows on different screens is confusing a lot already. On other screens they do horizontal scrolling/movement, but on Fields Management screen they are reserved for sorting, while they could be used for a quickier navigation. I don't think adding some screen-specific fallback keys is more confusing than that.
Yes, it's true using the meta key with the vim navigation keys may not work under all emulators. But that Esc problem you cite is due to a poor configuration choice. That's an issue for the distribution.
While a minimalist xterm will likely remain a hopeless case with respect to Alt, rxvt-unicode works flawlessly even with the Ctrl modifier. And other emulators purporting to be 'xterm' or 'xterm-256color' (openSUSE and Fedora) support the existing basic vim movement keys via Alt.
You stated that the the Left/Right arrow keys on the Fields Management screen were confusing yet they're clearly explained in the prologue. Personally, I thought such alternate use was an elegant solution to the single screen configuration requirement. Anyway, adding yet more Left/Right navigation keys for non-navigation needs is hardly less confusing nor will it provide "quicker navigation".
In summary, for all terminal emulators the arrow keys remain available. For most emulators the Alt vim approach provides a second means of navigation across all top screens. Your proposed third navigation alternative, available on only the Fields Management screen, would seem to benefit some xterm emulators only.
Perhaps someday I'll figure out how to support Alt under xterm. In the meantime, I'm sorry I can't support your merge request.
You helped turn my attention to the issue of those broken xterm vim navigation keys.
I've come up with a fix for xterm which has been pushed to our public repository. Several alternative xterm solutions are also documented in the commit message.
Thanks, it works in xterm with this commit. Now, what about reliable work in libvte? What did you mean exactly by poor configuration, is this about compatibility settings?
I'm glad xterm now works for you. It seems that poor ol' top is always having to adapt to some maintainer's configuration decisions.
With respect to the vte library, I falsely assumed that there was some configure option causing your problem. More importantly, I likely misinterpreted your reference to Esc
It now seems that you meant the Alt key was being treated like the Esc key, not that an Esc character was being transmitted. Anyway, from top's perspective it's the absence of a leading Esc character that could have caused a problem.
Under kde, the konsole app seems to work just fine, providing global shortcut key conflicts are eliminated. But konsole is not vte based.
The gnome-terminal uses libvte but I've experienced no problems. Besides, I haven't found a configure option which could influence that Alt key.
Which libvte based emulator(s) are giving you trouble and under what distros are they being used?
I've also tested those 3 terminals under Debian 10 and have found no problems whatsoever. That's true even with the original Alt vim keys implementation as well as the recent xterm patch.
The only quirk I found is Alt+h under xfce4-terminal defaults where one must disable 'menu key access' to avoid a help menu conflict.
With respect to the Ctrl+Alt vim key combinations, they also work with the un-patched 3.3.15 top, except for Ctrl+Alt+j. That particular problem was addressed last year in commit 42f0a341.
So I'm at a dead end when it comes to your libvte problem. Perhaps you could supply additional information. Or, if not, closing the issue/merge requests would be appreciated.