lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] lynx word bleeding?


From: Luke at Shellworld Support
Subject: Re: [Lynx-dev] lynx word bleeding?
Date: Sun, 30 Jan 2022 07:16:00 +0000 (UTC)

On Fri, 28 Jan 2022, Karen Lewellen wrote:

> previously as in for all the years I have used lynx, if I  move to another
> page, the contents of that page  is all I hear.
> Now though I am getting  bleed over from the previous page, in some spots, as
> if the content is still there.
> its honestly weird, because it has never happened before, ever.

What's interesting, is that this has never happened to you before. It has 
been happening to me for about 15 years, maybe more, in lynx. It 
especially happens with remote connections (such as one to shellworld), 
and not so much when using lynx on a local linux console.

The Control+L solution from Thorsten and Travis, to redraw the screen, is 
pretty much the only way to deal with this if it's happening, unless you 
can play with terminal emulation to fix it.

There is a secondary effect that happens with screen reading and lynx (or 
really anything ncurses based): dropped/added letters/words.
This happens, as best as I can tell, when you press space to advance a 
page, and some of the character positions on the next page, have the same 
letters/words in them as were on the previous page.
In that case, Ncurses doesn't bother re-drawing those locations with the 
new data, which would be the same as the old data. At least, that's what I 
think is happening.
The screen reader, however, is only reading new data, so skips the 
non-redrawn content, resulting in weird speech.

As a result of that one, which is far more common for me than the first 
one, I now nearly always hit my "read screen" command, every time I move 
to the next page. That causes the screen reader to start at the top, and 
process the screen as if it was completely new.
Maybe a bit harder to do if you're using Windows terminal emulation, where 
"the screen" is a somewhat different concept.

Alternatively, Control+L solves that one as well, since then every 
character is re-drawn. Although screen readers, at least some of them, may 
run into buffering issues if having a full page thrown at them in 
character mode, so I don't recommend Control+L for either problem, without 
also using a subsequent read screen or other reading command. In other 
words, let the re-draw finish before trying to process it with speech, 
don't rely on the re-draw to feed the speech.

Luke



reply via email to

[Prev in Thread] Current Thread [Next in Thread]