Re: lynx word bleeding?

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<
>
>