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): mc-4.6.0-4 How reproducible: 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 (comment #2). 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.