Re: LYNX-DEV highlighting bug in color slang version

[Klaus Weide]

On Fri, 18 Apr 1997, Laura Eaves wrote:

> > From: Klaus Weide <address@hidden>
> > ...
> > The "problem" (which I hesitate to call a bug) is not specific to SLang
> > or color.  It also appears with purely mono character attributes,
> > if you happen to have a terminal(emulator)/terminfo combo that
> > would make the different attribute combinations actually appear
> > different on the screen.
> > 
> > (see <URL: http://sol.slcc.edu/lynx/klaus/texts/attrnotes.txt>)
> 
> If you use color and see it all the time, it's a BUG.
> Your URL only documents it as a feature.

I tried to document "what is".  I didn't say it was good.
I would call it a "known limitation", are you happier with that?

> As for the problem occurring in other terminals and without -color,
> does the problem occur even when not compiled with SLANG?
> My reason for asking: highlight() in src/LYUtils.c contains the
> following comment:
> 
>       if (flag == ON) { 
>           /* makes some terminals work wrong because
>            * they can't handle two attributes at the 
>            * same time
>            */
>           /* start_bold();  */
>           start_reverse();
> #ifdef USE_SLANG
>           start_underline ();
> #endif /* USE_SLANG */
>       } else {
> 
> If compiling with SLANG messes up some terminals even when not using color,
> would a check for -color solve the problem? --

I don't give too much value to *some* of the comments in the code.
Some are *obviously* only of historical value and don't describe
correctly the code that surrounds them... (especially in the WWW/Library
part).

Anyway I assume that comment refers to the commented-out 
          /* start_bold(); */ 
and has nothing to do with the lines for USE_SLANG, which probably
came much later.

Also I don't understand what problem you want to solve now.
This seems to be a different problem from "Lynx forgets if a link
was in an emphasised section"??


> I've never tried Rob's style stuff.
> If you could point me to where I can pick it up, I have time
> to try it over the weekend.

You can find an *older* version, merged with some of the development
changes, in
      <URL: http://sol.slcc.edu/lynx/klaus/merged/oldRP/>
but cannot recommend that myself.. We're all waiting for his recent
stuff.

> As for whether it's a better solution in all cases, I use the
> color slang stuff because I have trouble seeing reverse video
> and can't read the lynx status line otherwise.

But the "Lynx forgets about highlighting on Lynx" problem doesn't
cause any of those problems - right?

> If Rob's style stuff doesn't let me redefine colors to something I can see,

That's the idea, I think...

> then I can't use it, and will continue using/supporting the slang stuff.

> As for my fix being overkill, the only alternative I saw was to search back
> on the buffer for a "start underline" character, if there is such a thing
> -- and that seemed a lot klugier and error prone.  Also, my fix is quite
> simple and safe, if you look at it.  

Right, I didn't think it was unsafe.

> The only reason the diff was so large
> is that I had to pass an extra arg (me->inUnderline) in all the calls to
> HText_beginInput() and HText_beginAnchor().

And that's the reason why I don't like it that much.  Information on
visual attributes doesn't seem to belong in HText_beginAnchor IMHO.
Just imagine when we (Rob?) want to make Lynx understand more attributes -
should we then add an argument for each of them?  So this doesn't seem
like a good thing to base further development on.

It also couldn't deal with things like 
<A HREF=X>a <em>partially</em> emphasized</A> link.  (I don't know whether
Rob's code does, or even if it is particularly desirable.)
I think a more general implementation of the highlight() code is
desirable, including the capability to highlight (with appropriate
different color/attribute) a search string within the link so that
we can get rid of some unnecessary screen refreshes after WHEREIS
searches...

> PS: I updated my temporary web page at http://www.intac.com/~leaves/
>     but haven't changed the diff files of my fixes.  Since fotemods.zip
>     seems to be unstable lately, I'm putting off picking up more of fote's
>     fixes until things settle down.  I actualoy have this version built
>     on 3 machines and a few people are using it.
>     I've directed them to send bug reports to lynx-dev.

IMHO What you are doing is the right thing, offer your changes separately
so people can decide whether they want them.  Even better if you could
now and then check whether your patches also still work against our
development code at <URL:http://sol.slcc.edu/lynx/current/>.

I will put your "submit button" change in the development code when
I get around to it.

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;