lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev about lynx.cfg


From: Foteos Macrides
Subject: Re: lynx-dev about lynx.cfg
Date: Wed, 27 May 1998 20:41:24 -0400

"T.E.Dickey" <address@hidden> wrote:
>> I don't know way legacy bugs you have in mind, since
>> v2.7.2 has no curses color support (only via slang)
>> nor any DOS/WIN/NT support. 
>
>enabling traces, with all versions (2.7.2 with slang,
>as well as 2.8) causes the colors to not be displayed
>properly.  I noticed this while investigating the
>color-style code.  I assume that one of the fprintf's
>involved in the tracing has a side-effect (but until
>that's resolved, I cannot make progress with the
>color-style bugs).  So I am working on the trace code
>- which is mostly done.  (On some platforms, I am
>seeing a problem switching between enabled/disabled
>mode, as well - will be looking at _that_ next, before
>trying to find the side-effect that is breaking color
>behavior).

Is the problem specific to sending trace messages to
the screen?  When sent to Lynx.trace and then viewing
that as a file, any characters which might be confused
with color sequences should be filtered out by the
rendering code.  I personally can't see any reason for
ever sending trace messages directly to the screen.
That's just a makeshift design from the original Lynx
which amounts to garbaging the display and causing
messages to whizz by often too quickly to be sure you
could catch what you want to see, and without ability
to (WHEREIS) search for it.  Note that GridText.c
functions include special characters in trace messages,
which perhaps may be treated as color controls if sent
directly to the screen rather than via the rendering
code with its filters or converters to "safe" byte
sequences (presumeably now OK again thanks to Leonid).


Just in case that message from the foreground noise yoyo
might induce you or someone to include configuration
file paths in general user screens, note in anonymous
or otherwise captive accounts displays of local file
system paths heretofore have not been considered a good
idea.  If the user has shell access, then Lynx can be
invoked with -trace to get that information.  Otherwise,
TRACE mode can be invoked only via ^T, and only diagnostic
info for subsequent actions, not the setup info with
explicit local file system paths established by the
sysadmin or Lynx installer, will be available to the
general users.

I also don't understand why you're spending so much
time on the color styles stuff.  Despite that exchange
between you and Henry when he stated with such "confidence"
that Klaus added that into to devel code, and you replied
"If you say so.", it was you, not Klaus, who did that, as
recorded in the v2.8 CHANGES file, and without any knowledge
of the style sheet specs.  You also must, yourself, realize
that your adding curses/ncurses/pdcurses color support makes
the color styles stuff unnecessary for color support, per se
(i.e., whether or not Lynx is built with slang).  Did you
miss the message from Rob back when he lost his job
stating he now recognized that the way he had implemented
the styles stuff was a dead end, and that one advantage
of his job loss was that he'd have the time to redo it from
scratch in a manner that could really be compliant with the
CSS2 specs and could be coordinated with eventual DOM support
(both of which are now geared toward accessiblity issues of
great importance to Lynx's blind users).  It doesn't appear
that he did find the time, but anyone who might try to do
so must also cope with all that dead end code you
incorporated from Rob's first attempt.  Sigh...

Oh well, time to butt out again. :)

Fote
-- 
Foteos Macrides




reply via email to

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