lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev lynx-2.8.2dev19 commandline patch


From: Klaus Weide
Subject: Re: lynx-dev lynx-2.8.2dev19 commandline patch
Date: Fri, 12 Mar 1999 10:41:33 -0600 (CST)

On Wed, 10 Mar 1999, Vlad Harchev wrote:

>   Here is a patch that allows the use of '--' prefix for commandline options
>  ( '-' can also be used ), same for options redirected to stdin. This means 
>  that '-localhost' and '--localhost' mean the same thing for lynx. 

It would make more sense if the long form also implied a more
natuaral syntax for giving boolean values: --localhost={yes,no} instead
of --localhost{+,-}.  Without that, I don't like it that much.

>  If EXTENDED_OPTION_LOGIC is defined and ==1 (it will be defined to 1 if 
>  it wasn't defined ) then the extended commandline option logic 
>  will be used. It means that '--' will be accepted and will be treated as an
>  end of options. Anything after it will be treated as URL even if begins with 
>  '-' or '--'. Also the number of URLs passed will be counted and stored in 
>  variable 'url_count'. Search for a symbol FILLTHIS in this patch and fill 
>  in actions lynx should take when it encounters several URLs passed - I don't
>  know how to put and what to put in message catalogue ( or disable the 
>  execution of the branch ). This works for both regular commandline options
>  and for ones redirected to stdin.
>  
>  May be lynx help message should be modified to accomodate the changes.

You can just add the ones you want with gettext("my new message") - don't
worry about the catalogue too much.

> +#if !EXTENDED_OPTION_LOGIC    
>      if (*arg_name != '-') {
> +#else
> +    if (*arg_name != '-' || no_options_further==TRUE ) 
> +      if (url_count>1) {
> +        /* here we've encountered excessive url - this seems to be an 
> +            ill-formed  command-line */
> +           /*FILLTHIS or remove this branch if you don't consider this an
> +            error*/


I am still against treating this as an error.

Possible useful behavior: use only last URL, but store preceding ones
in 'G'oto recall list.

   Klaus

reply via email to

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