Re: lynx-dev When unhighlighting some highlighted links, lynx draws them incorrectly

[Vlad Harchev]

On Tue, 16 Mar 1999, Klaus Weide wrote:

> On Sat, 13 Mar 1999, Vlad Harchev wrote:
> > 
> > On Mon, 15 Mar 1999, Klaus Weide wrote:
> > > In this *particular* case, I don't know whether it's worth starting
> > > a new source file, since most of the change is adding to GridText.c
> > > anyway.
> > > 
> > >    Klaus
> > > 
> >    Sorry about that. If you (developers of lynx) insist, I can rewrite the
> >  patch this way.
> 
> You are now a lynx developer - it doesn't take more than sending patches
> and being on the list.  At least that's always been my understanding.
> 
> Tom is integrating the patches, so it's finally up to him whether he
> wants to add a new source file or not; I was just pointing out that some
> more files and scripts would have to be changed.  You may just want to
> take that into consideration.
>
  
    Yes I will. 
 
> > And please, mail me (or in mailing list) about patches
> > I'm sending - whether they are accepted or not, rather than silently
> > rejecting.
> 
> (Others have replied to that.)
> I am cc'ing you until you complain, since I don't know whether you
> are losing messages.
  
   It seems that I'm not loosing messages, so please don't cc: me. And
should I cc: to you in replies?

> >   I can rewrite previous commandline patch the way you and I feel it
> >  useful.
> 
> (To repeat myself:) My preference is that IF "--xxx" flags are recognized,
> THEN (for those long style flags, at least) the syntax for forcing on/off
> instead of toggling should also change (from "-xxx+" and "-xxx-").
> (I don't know how this fits in with the visions various people have for
> revamping the whole flags and options handling.)
> 
> I don't want 'lynx  URL-1 URL-2 [...] URL-N' to be suddenly treated
> as an error - it works fine as far as I am concerned.  But making
> URL-1 ... URL-N-1 available for 'g' command recall after startup
> would be a nice touch.
> 
> 
>    Klaus
> 

    May be style like -xxx+ or -xxx- should be supported forever, and
  --xxx=on or --xxx=off should be added?

   Frankly speaking, I think there should be a fronted script to lynx that
 will partially parse comandline. In that case such frontend should
 generate HTML file containing of links to URL-1 .. URL-N-1 and load that 
 file to lynx - so user can visually select one of the URLs passed.
 Another idea is to make command line option with argument, that will
 add it's argument to list that 'g' uses. Both of these approaches seem
 useful to me (1st seems to be like 'do it yourself').  

   I'l try to add this to the next developer release, since I'm confused
by the need of sending patches to patches.

  BTW, I hope Thomas E. Dickey understood that commandline patch I've sent
was partially template -  it contained the following piece of code:

#if !EXTENDED_OPTION_LOGIC
    if (*arg_name != '-') {
#else
    if (*arg_name != '-' || no_options_further==TRUE )
      if (url_count>1) {
        /* we've encountered excessive url - this seems to be an
ill-formed
           command-line */
           /*FILL_THIS or remove this branch if you don't consider this an
            error*/
        }
      else
      {
        url_count++;
  
 If no modifications are made in the scope where /*FILL_THIS ..*/ comment
is placed and EXTENDED_OPTION_LOGIC is undefined or =0, the lynx will load
only the 1st URL passed. When writing patch I supposed that somebody will
decide what behaviour lynx should have, and fill in (may be) error
reporting code. But it's safe to not define EXTENDED_OPTION_LOGIC - in
that case lynx will have old behaviour when handling multiplie URLs, and
it won't accept '--' as the end of options. 
 
 Best regards,
 -Vlad