Hello, Aura Kelloniemi, on Fri 13 Nov 2015 11:18:01 +0200, wrote: > There remains four issues: one that I reported already which can be > reproduced with less and a long text file (just press down and right arrow > keys in less repeatedly and watch how the braille display behaves).
This looks like a bug in VTE: here is what brltty gets when scrolling over the GPL-3 licence text: brltty: insert 66 from 1245 brltty: 'ou modify it: responsibilities to respect the freedom of others. :' brltty: caret move to 1311 brltty: delete 65 from 0 brltty: ' The GNU General Public License is a free, copyleft license for ' brltty: insert 1 from 1246 brltty: ':' brltty: caret move to 1247 So at some point the VTE widget inserted ':' without dropping the previous one. No wonder brltty gets it wrong :) This seems to happen when the additional line shown by less is an empty line. With a mere file with only empty lines, brltty only gets these events: brltty: insert 1 from 23 brltty: ':' brltty: delete 1 from 0 brltty: ' ' repeatedly. > The other is a bug in BRLTTY's BrlAPI braille driver. With it, I get double > cursor. The cursor is shown both by BRLTTY (which has its own cursor drawing > logic), but also by BrlAPI. I hadn't initially understood what you meant by "double cursor". So you don't mean that you have two cursors shown on different cells, but two cursors shown on the same cell, which can be seen by making them look different, right? I guess I understand why: the brlapi driver gets told to render text, dots (with the cursor drawn by brltty), and the cursor position. It thus passes that through brlapi. The second brltty then draws the text (with the cursor position), dots (and draws the cursor there again). We do prefer to have the brlapi driver pass the cursor position to the second brltty, for displays which can show it. Actually, we didn't plan brlapi clients to draw the cursor, so the bug would be that the first brltty draws the cursor. Dave, could there be a way for braille drivers to tell the core "I will handle drawing the cursor as dots"? It could make sense for instance if the device has another way to represent the cursor than braille dots (which is the case here in the brlapi driver). > The first is yet another bug with trailing whitespace: > In a text editor the cursor position is not shown correctly, Indeed, it should be easy for VTE people to reproduce it. Samuel _______________________________________________ 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
