Bug 98237 - mc - keyboard shortcuts in confirmation dialogs don't work
Summary: mc - keyboard shortcuts in confirmation dialogs don't work
Status: CLOSED DUPLICATE of bug 120744
Alias: None
Product: Fedora
Classification: Fedora
Component: mc   
(Show other bugs)
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2003-06-28 18:34 UTC by Maciej Żenczykowski
Modified: 2015-01-08 00:05 UTC (History)
3 users (show)

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

Attachments (Terms of Use)

Description Maciej Żenczykowski 2003-06-28 18:34:26 UTC
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 12:38:29 UTC
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 21:23:21 UTC
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 15:03:23 UTC
Still present in Fedora Core 1

Comment 4 Leonard den Ottolander 2004-04-19 13:04:33 UTC
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 18:56:54 UTC
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.