Bug 173654 - mc alt behaviour broken with new Xterm resources
mc alt behaviour broken with new Xterm resources
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: mc (Show other bugs)
4
All Linux
medium Severity low
: ---
: ---
Assigned To: Jindrich Novy
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-18 15:18 EST by Adam Pribyl
Modified: 2013-07-02 19:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-12-15 04:43:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Pribyl 2005-11-18 15:18:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.11) Gecko/20050728

Description of problem:
There were pushed new resources for xterm according bug 155538. In xterm-205-1.FC4 therefore all alt+letter combinations give accented letters instead recalling mc functions. The change that causes this is most probably removal of
! Bug fix for bugzilla bug #49315
*VT100*eightBitInput: false

I do not know how to solve that other way than changing xterm resources or by changing mc option Display bits/Full 8 bits input, which however prevents me to type accented letters in mcedit, so I am reporting it as behaviour change, which could be pretty annoing for beginners.

Version-Release number of selected component (if applicable):
mc-4.6.1a-0.15.FC4

How reproducible:
Always

Steps to Reproduce:
1. use new xterm
2. start mc
3. press e.g. alt+o for quick find


Actual Results:  You get accented letter o.

Expected Results:  quick search prompt

Additional info:
Comment 1 Jindrich Novy 2005-11-19 02:04:21 EST
Yes, I can reproduce it. In my opinion the error is on the xterm's side as the
alt+whatever combinations work fine under gnome-terminal, konsole, etc. You
correctly stated that it might be caused by bug 155538.
Comment 2 Jindrich Novy 2005-11-22 03:46:06 EST
Marking this as a duplicate of the bug causing this.

*** This bug has been marked as a duplicate of 155538 ***
Comment 3 Adam Pribyl 2005-12-12 13:21:16 EST
After latest update of mc-4.6.1a-4.FC I am not able to get it satisfactionaly
working under Xterm - it resembles me debian brokeness of mc.

With default XTerm resources I have either working alt key, when I switch off
8bit input in mc menu but I am not able to write iso-latin-2 letters, or I am
able to write iso-latin-2 letters with 8bit input on, but then I am not able to
use alt key combination. 
Changing XTerm resources did not help anyhow this time.

This is the worst state ever... IMHO.
Comment 4 Jindrich Novy 2005-12-12 13:43:44 EST
This is really weird. I haven't touched any code related to this. The both -3
and -4 are almost identical with a fix for PHP sytax, directory concatenation
and that the extension file launches evince instead of gv....

Have you tried to install the -3 mc version and did it return it to a correct
behaviour?
Comment 5 Adam Pribyl 2005-12-12 14:09:48 EST
Yes. I imediately downgraded to -3, that works. I try to be more specific:

mc -3
1.XTerm resource default from FC4
   8bit input on - iso-latin-2 letters OK, alt+s gives accented o
   8bit input off - iso-latin 2 letters can not be written some functions
invoked instead, alt+s quicksearch
2.XTerm resource  diff XTerm XTerm.my                               
  185a186,190
  > 
  > ! Bug fix for bugzilla bug #49315
  > *VT100*eightBitInput: false
  > 
  > *VT100*backarrowKey: false
   8bit input on - iso-lation-2 letter OK, alt+s quicksearch
   8bit input off - iso-lation-2 letter can not be written, alt+s quicksearch

mc-4
 with both resources it behaves same way as 1.


Sorry to mix it with resource changes, but these helped me with -3.

Maybe this is "finaly" correct behaviour, but there has to changes something,
seems like XTerm is processing keys trought XTerm and it did it itself before.

Comment 6 Adam Pribyl 2005-12-12 14:14:46 EST
I meant:
Maybe this is "finaly" correct behaviour, but there has to changes something,
seems like MC (!) is processing keys trought XTerm and it did it itself before.
Comment 7 Jindrich Novy 2005-12-12 16:50:50 EST
What version of xterm do you have?

Could you try it again with xterm-207-7 installed?
Comment 8 Jindrich Novy 2005-12-13 05:32:38 EST
Is was successful to reproduce the problems you noted (alt-s prints o' ...) with
xterm-205 and the problems are gone with xterm-207-7 and xterm-207.FC4. Could
you confirm that? I can ask jvdias to release xterm update then.

the only addition to Xresources I have is:
XTerm*font:             -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
XTerm*boldFont:         -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1

and is pretty empty otherwise.
Comment 9 Adam Pribyl 2005-12-13 07:43:10 EST
I can not update to xterm-207-7 as it requires updating complete system. I used
however the 207-7 XTerm, XTerm-color and UXTerm resource files (BTW: they were
moved from /usr/X11R6/lib/X11/app-defaults to /etc/X11/app-defaults in 207) and
it seems (!) that with 207 resources mc works again OK. 

I'd be very glad if someone else could test default FC4 setup before any further
release, as I'm really getting lost in all these xresources vs. (u)xterm vs. mc
vs. locale. (As you may notice I found also using uxterm and switching locale
makes difference.)
Comment 10 Adam Pribyl 2005-12-13 13:13:55 EST
I missed that there is also 207 xterm for FC4 in updates/testing. If that could
be released it would be nice, but still one more vote for that would be welcomed.
Comment 11 Jindrich Novy 2005-12-15 04:43:44 EST
Jason release an update for xterm-207.FC4, so closing ERRATA.

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