Red Hat Bugzilla – Bug 98237
mc - keyboard shortcuts in confirmation dialogs don't work
Last modified: 2015-01-07 19:05:40 EST
Description of problem:
I just upgraded to mc-4.6.0-4 for RH9 (via an update from RH8) and keyboard
shortcuts in confirmation boxes don't work (ie press F8 for delete and then 'n'
for no doesn't work - it's ignored) they are also displayed in the wrong color
(ie they are not highlighted).
I don't have a fresh RH9 installation box to verify if it'll happen there also
(however this has happened on two drastically differently configured (soft and
hard) desktop and notebook RH 7.1->8.0->9 upgraded machines)
Furthermore (probably related) when the quit confirmation dialog comes up the
title (Midnight Commander) is now blue on white (used to be yellow on white).
Version-Release number of selected component (if applicable):
Always on both machines (all of locale info set to straight en_US)
Just another annoying function of mc(?)
running 'mc' in an 'xterm' on a fully up2date rh9 system
[mc is running with colour and non-ascii chars enabled]
when viewing a text file beginning with the letter 'l'
(i.e. echo "l" > /tmp/file; run 'xterm' then 'mc' and select /tmp/file and press
F3 for view or F4 for edit) results in the 'l' not being displayed
(instead you can still see the upper-left corner character from the file
list) while the entire rest of the screen is OK.
I've had this happen with various characters in the first column of the
editor (not only on the first line) - never seen this behaviour on the console.
I'm not convinced this is an 'mc' error - might be xterm's fault.
Xterm also seems to miss a few chars from time to time while displaying large
amounts of text - maybe this is the same problem?
One more stupid case:
the ampersand '&' key works weird in many dialog boxes.
For example in the mcedit (mc internal editor) search (F7)
dialog box pressing '&' while typing in the search string
results in toggling the case sensitive option...
Still present in Fedora Core 1
You forgot to mention the character set you are using. I presume this
is something different than UTF-8.
You are discussing three issues here (they possibly have the same
cause, but that is not certain). As I hadn't seen this bug report I
filed two of them as bug 120744 (original bug report) and bug 120735
I can also reproduce the issue in comment #1, also inside a
gnome-terminal. After editing the l might also end up in the upper
left corner of the panel view.
I'll file comment #1 as a separate report, cc Maciej to all three and
close this as a dup.
*** This bug has been marked as a duplicate of 120744 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.