Thanks Travis,
One new element happens now when sending emails using this updated
compiled Lynx from my gmail account as well, or downloading items sent to
me as attachments.
I do this several times a week, processing research, etc.
Now lynx either does not respond to the view as html link or the download
link. Or most unusually if sending an email with an attachment, I get a
408 time out error.
Granted fortunately as has been the practice at shellworld an older lynx
copy is present.
So, I can roll back and try to send or process the email that way.
still, there is something odd about the upgrade for that to happen in lynx
now.
I do admit to a positive from this upgrade,
places like the Washington post, and yahoo news, no longer need me to
either use control v for links to be active, or to turn of sending the
user agent.
so, it is a mixed blessing I suppose.
Karen
On Tue, 1 Feb 2022, Travis Siegel wrote:
Her screen reader is simply that, it doesn't do anything else, it's a screen
reader, (just like almost all screen readers are). As for the problem with
lynx, I suspect it happened when shellworld reinstalled their recent version
of lynx. As mentioned before, it was probably compiled with ncurses
support, and that's particularly nice for sighted users, what with the colors
and cursor tracking, and the like, but all of the features that make it so
nice for sighted folks are usually the things that make it not so nice for
screen readers. On the other hand, there is probably a terminal setting
that will prevent lynx from behaving that way. It's been my experience that
changing to ansi typically solves the problem, though vt100 (which is usually
the default)works just fine in most cases, it's only when programs expect
fancy terminals that things break.
Karen had nothing to do with this particular breakage.
On 2/1/2022 1:43 AM, Bela Lubkin wrote:
Karen Lewellen wrote:
> Honestly?
> Well I must have an advantage using a DOS screen reading program arctic
> business vision to come here, as I have never encountered the slight
> character overlay I am getting now, and it does not show up everywhere
> either.
> the control-l solution is working fine though on those few moments.
> Have never encountered the page problem one until this particular DOS
> computer which is much faster than any I have used previously with a
> faster processor and almost a gig of memory.
You said this wasn't happening, and then it started happening. So
something changed to cause it.
This faster 1-gig PC, how long ago did you switch to it? Did the
problem start at the same time?
I don't anything about the Arctic screen reader you're using. Is it
truly a screen reader (does nothing else); or does it also handle the
terminal emulation which collects the screens which it then reads?
The issue you're having is entirely typical of when the software making
the display using ESC sequences (here, Lynx via probably ncurses) is
using a different terminal type definition than the software
interpreting the ESC sequences (whatever terminal emulator you're using
-- built into Arctic or separate).
'using a different definition' can mean something like one things
'VT100' while the other thinks 'ANSI'. But even if the names are the
*same*, there is no guarantee their interpretations of them are the
same. At this point in history, telling a piece of Unix-ish software
that you have a 'vt100' probably produces fairly similar results on
almost all systems. But terminal emulators which claim to emulate
'vt100' are all over the map.
So, did you switch terminal emulators? Upgrade versions? Change which
terminal type it is instructed to emulate? If your terminal program
settings got erased and you had to re-create them, you might have
inadvertently changed it (by way of having set it to some non-default
value in the past, and now it's reset back to default).
To clarify some of the above tangle down to bare bones; to the thing I
think is most likely to have happened:
* If you changed anything about your terminal emulator -- different
emulator, version update, reinstall, whatever -- you probably fell back
to its default terminal type. You need to make it match (in terms of
compatibility, *not* merely name) with what Lynx thinks you're using.
A particularly likely, common mismatch is if one thinks 'vt100' and the
other thinks 'ansi', 'xterm', or 'linux'. Those are all 'compatible
enough' that Lynx will behave adequately well -- with some glitches like
words left behind after a screen update.
One way to approach it is: look at the emulator's list of possible
emulations. For each one, tell the emulator to use that; tell Lynx the
same name; TEST. So if the emulator supports 'vt52', tell it to use
that, then set TERM=vt52 and run Lynx -- does it behave better or worse?
Iterate through all the choices until you find a setting which pairs up
well. ('set TERM=vt52 and run Lynx' is itself a possible area of
confusion depending how accounts are set up on the system, your
familiarity with *ix shells, etc.)
> Bela<
