Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 98237 - mc - keyboard shortcuts in confirmation dialogs don't work
mc - keyboard shortcuts in confirmation dialogs don't work
Status: CLOSED DUPLICATE of bug 120744
Product: Fedora
Classification: Fedora
Component: mc (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2003-06-28 14:34 EDT by Maciej Żenczykowski
Modified: 2015-01-07 19:05 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 13:56:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Maciej Żenczykowski 2003-06-28 14:34:26 EDT
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):

How reproducible:
Always on both machines (all of locale info set to straight en_US)
Comment 1 Maciej Żenczykowski 2003-10-03 08:38:29 EDT
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?
Comment 2 Maciej Żenczykowski 2003-10-07 17:23:21 EDT
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...
Comment 3 Maciej Żenczykowski 2003-11-06 10:03:23 EST
Still present in Fedora Core 1
Comment 4 Leonard den Ottolander 2004-04-19 09:04:33 EDT
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 ***
Comment 5 Red Hat Bugzilla 2006-02-21 13:56:54 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.