Samuel Thibault <[email protected]> writes: > Samuel Thibault, le Sun 13 Sep 2015 17:31:11 +0200, a écrit : >> Samuel Thibault, le Sun 13 Sep 2015 16:10:48 +0200, a écrit : >> > Aura Kelloniemi, le Sun 30 Aug 2015 23:40:03 +0300, a écrit : >> > > Orca still notices cursor movement and the >> > > added characters, so the problem must be in BRLTTY. >> > >> > Well, perhaps Orca circumvents the issue by being not efficient, but the >> > bug really is in VTE: the received events are "delete 1", "move caret", >> > "delete 1", "move caret", etc. There is never any insertion event. >> > It's not surprising that brltty considers that the spaces on the right >> > of the cursor get removed one by one, up to the trailing \n... I'll >> > have a look inside VTE. >> >> I have submitted https://bugzilla.gnome.org/show_bug.cgi?id=754964 , you >> will probably want to try the attached patch. > > This was fixed and now available in vte2.91 version 0.42.1
Thanks for tracking this one down! These are the kind of bugs that really ruin the linux desktop accessibility experience. Kind of reminds me of the time when Java Swing applications had a off-by-one error when it came to cursor position in any text field. Or the issue with Eclipse, where it would miss insertion events when doing autocomplete (I actually got the eclipse team to fix it, which involved several hundred lines of code). I suspect there are quite some of these still out there. Again, thanks for tracking it down. -- CYa, ⡍⠁⠗⠊⠕ _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
