Rename file ; keyboard echo fails after 2nd shifted char +...

[Scott Cowles Jacobs]

In Nemo 1.8.4-1.1, the rename box stops echoing characters after the 2nd shifted character (provided there is SOMETHING non-shifted after the first shifted char).

Example: I want to enter "ThisIsAFileName", but the only thing visible in the box is "This"
"ThisisaFileName" shows only "Thisisa"
"HHHH" works, but "HhHHHHH" shows only "Hh"
I noticed this with capital letters, but then, on an impulse, tested shifted non-letters...
"!111!!!" echos only "!111"
[I just noticed something: "HHHH" only works if YOU HOLD DOWN THE SHIFT KEY (i.e. if you type <shift> "HHHH" it works, but NOT if you try <shift>H<shift>H<shift>H<shift>H ==> only "H")]

<backspace> counts as a letter: If I type "HH", and then <backspace>, there is no more echo: "H"
If I enter "HH" and backspace twice, there is "" - type "ffff" fine, but then try to type "H", one is left with only the "ffff"
BUT: <shift-backspace> seems to work the same as <backspace>, but
"HH" <shift-H-H-backspace-backspace-H-H > (<shift> pressed and HELD) ==> "HH"

Note: Nemo is still reading the keyboard input, and when <enter> is pressed, the name will show everything.

If <ctrl-v> is used to copy into the rename box, it acts the same as a shifted char:
If the clipboard contains "box", <ctrl-v><ctrl-v><ctrl-v> yields "boxboxbox",
but if <ctrl-v> then a space, then <ctrl-v>, one gets only "box ".
If <ctrl-v> then a backspace, then <ctrl-v>, one gets only "bo"
[Note that SOMETIMES, the FIRST <ctrl-v> yields nothing - it seems intermittent - maybe every 3rd or 4th attempt...]

If one types something (say "tom ")and selects it and delete/copies (<ctrl-x>),
then if one does <ctrl-v-v-v> one sees "tom tom tom ", but if one
does <ctrl-v><ctrl-v><ctrl-v> one sees nothing at all.
If one combines <shift> and <ctrl> (say, typing "Tom " (capital "T" this time), then even the <ctrl-z> doesn't seem to have an effect - "Tom " remains in the box, selected...

I speculate, that if other modification keys (<alt>, <windows>, OTHER <alt>, etc.) can generate visible output (especially with other languages - like the Euro symbol in German), they may have the same effect as <shift> and <ctrl>, but I have not tested them.

I summarize my results as follows: the second time a character-modification key is pressed seems to turn off echoing.

---------------------------------------------
scott@scott-AsusM2N68-AM-Plus:~$ uname -a
Linux scott-AsusM2N68-AM-Plus 3.13.0-29-generic-tuxonice #53~ppa1-Ubuntu SMP Fri Jun 6 17:27:38 UTC 2014 i686 athlon i686 GNU/Linux
scott@scott-AsusM2N68-AM-Plus:~$ lsb_release -dsc
Ubuntu 14.04 LTS
trusty
scott@scott-AsusM2N68-AM-Plus:~$ echo $DESKTOP_SESSION
Lubuntu

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Hector Hurtarte (hectorh30)]

I ran nemo from the terminal to see if it echoes anything when the problem occurs, but nothing. Is there any other way I can get more information about the problem? (verbose mode or something). Thanks in advance.

[Scott Cowles Jacobs (scott092707)]

I solved this problem, which appears to be the same problem that caused Chromium 34 to sometimes not accept keyboard input, by switching from ibus to fcitx (as was suggested somewhere in the discussion on Chromium).

All I did was to go to synaptic and search for fcitx, and select for installation (it loads a few more pkgs). I did not have to remove ibus, and the keyboard icon in the notification section of the panel now looks different, and apparently concerns fcitx now, not ibus.

[Hector Hurtarte (hectorh30)]

Thanks a lot Scott, it worked for me. It also solved a problem I was having with Sublimetext, where it wouldn't recognize characters like 'á'.