xterm-201 eats Alt-7 and prints the previous word in the terminal instead. Reproducible: Always Steps to Reproduce: 1. Press Alt-7, 2. Watch as the previos word in the term is printed. Expected Results: The same thing as when you press Alt-{1,2,3,4,5,6,8,9,0}. Works fine in xterm-200.
oh man, it eats a lot more than that. I'm toying with hardmasking it.
coma, you did etc-update, btw, right?
Yes, I did.
Indeed, it also eats ' " and all sorts of characters produced with dead keys or meta, e.g. meta < < gives (gave) me
Indeed, it also eats ' " and all sorts of characters produced with dead keys or meta, e.g. meta < < gives (gave) me « It also takes about 10 seconds to start and complains with the following warning: "Warning: Missing charsets in String to FontSet conversion". Tested in a UTF-8 environment on x86 & amd64 with same result. Locale is en_GB.utf8 Command line is xterm -fg black -bg '#fefefa' -fa "-bitstream-bitstream vera sans mono-medium-r-normal--0-0-0-0-m-0-iso10646-1" -fs 9 -lc I am back to normal with emerge '<xterm-201' BTW, +tb removes that silly toolbar but I couldn't remove the surrounding thin black line. Any hint?
xavier, i entered in the ~/.Xdefaults file: xterm*toolBar: false and then reloaded it with xrdb -merge ~/.Xdefaults and neither the toolbar nor the black surrounding area don't appear. about "eating", i must say that most of the times (3 of 9 tries, it does, the rest fails), it doesn't paste anylonger using shift+insert, but i'm still working on this one, as it might not be a bug after all. in fact, the issue is more complicated: the characters inserted via xclip were all printable (are present on keyboard), but not all were normal characters [A-Za-z0-9]. on one of the machines, the shift+insert combination worked 7 of 9 times, but on some other machine, only 3 of 9 tries worked (consecutive tries, without altering any configuration file). as said in a comment on planet.g.o, the text *was* present in the clipboard, as the mouse middle-click caused the text to be pasted. this is just a comment, i'll try and dig some more with this problem - until then, in the stable environments i'll stick with 200-r1 (201 gone ~ as of today).
Nice try Alin! I added the suggested ressource. Same as with +tb Black border remains. Warning remains. 10+ seconds load time remains. Still can't type quotes or characters with dead keys. Problems happen every time I try.
well, the only thing i can think about is: "have you replaced the /etc/X11/app-defaults/XTerm* with the new ones from the 201 version?". if the answer is "yes", then, other than this, i can't think of anything else - i won't tell you "works for me", as is not a solution.
Thomas, I think I need your help/input/feedback on these issues :)
There are several pieces here. The alt-7 (I'm not sure about that - will review my changes and see what might have broken). I've a bug report related to the sched_yield() code - that's my guess for the 100% CPU (and have been working on it). The thin line - that's a resource-file thing (I've an unrelated report regarding the resource file - and have a fix). Missing charsets is an old harmless issue (not a new bug).
Referring to #90751, it appears that the CPU usage problem is not a bug in xterm. It happens to show up in xterm because the toolbar configuration initializes the popup menus at startup rather than as they are first needed.
ok people, xterm-202 in portage now. please try and report, unless thomas previously stated on this bug that 203 would bear the fix.
202 eats Alt-7 in the same way as 201 did.
Thomas, please have a look see here: https://bugs.freedesktop.org/show_bug.cgi?id=2475
I have a fix for the CPU usage in upcoming patch #203.
Please everyone, test xterm-204 that just went into this tree to see if it solves any of your issues. It works pretty nicely for me.
(In reply to comment #15) > Please everyone, test xterm-204 that just went into this tree to see if it > solves any of your issues. It works pretty nicely for me. 204 works nicely for me, both on x86 & amd64. Tested with -Xaw3d -toolbar +truetype +unicode
thanks Xavier. I'm closing this bug then, since I've just unmasked 204 in portage. Thanks a bunch, Thomas.
It still eats Alt-7.
Who was the original reporter for this bug? I see a complaint in bug 101333 also related to eightBitInput. Since that feature is working for me, I'm guessing that there is some configuration difference that's making it not work for some people. Perhaps opening a new bug, telling _what_ isn't working (the complaints are too vague to do more than guess what's wrong) would help.
(In reply to comment #19) > Who was the original reporter for this bug? I reported the bug that it's not possible to send Esc+7 using Alt-7 (using eightBitInput or metaSendsEscape) in xterm 201 (actually 200+ now). The other problems added to this bugreport I know nothing about. > I see a complaint in bug 101333 > also related to eightBitInput. Since that feature is working for me, I'm > guessing that there is some configuration difference that's making it not > work for some people. Perhaps opening a new bug, telling _what_ isn't > working (the complaints are too vague to do more than guess what's wrong) > would help. Fine, I'll do that since this bug was falsely marked as resolved.
https://bugs.gentoo.org/show_bug.cgi?id=104818
