lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev keeping lynx in sync with gettext


From: dickey
Subject: Re: lynx-dev keeping lynx in sync with gettext
Date: Fri, 5 Feb 1999 13:43:55 -0500 (EST)

> 
> In a recent note, address@hidden said: 
>  
> > Date: Fri, 5 Feb 1999 05:25:55 -0500 (EST) 
> >  
> > my preference is to replace the existing CTRACE syntax with a macro that 
> > can be easily ifdef'd.  I left FM's structure intact because most of the 
> > effort in converting to the current form was validating the transformation 
> > - 
> > now that they're all identified, changing the definition would be more 
> > reliable.  for example: 
> >  
> >     #ifdef CTRACE_CODE 
> >     #define CTRACE p LYCtrace p; 
> >     #else 
> >     #define CTRACE /*nothing*/ 
> >     #endif 
> >  
> > so we could replace 
> >     CTRACE(tfp, "something\n"); 
> > with 
> >     CTRACE(("something\n")) 
> >  
> Hmmm.  Yes, but go the other way, please: 
>  
>       #ifdef CTRACE_CODE 
>       #define LYCtrace(p) CTRACE p;  /* (typo corrected) */ 
>       #else 
>       #define LYCtrace /*nothing*/ 
>       #endif 
>    
>   so we could replace 
>       CTRACE(tfp, "something\n"); 
>   with 
>       LYCtrace(("something\n")) 
>    
> So the transition can be made progressively rather than 
> catastrophically -- residual calls to CTRACE would continue 
> to work (but not be suppressed by the switch) while the 
> preponderance were converted.  This also avoids invalidating 
> local patches that contain CTRACE calls.  The same pervasive 
> set of lines need to be systematically modified, so it's 
> a break-even in that respect. 
>  
> -- gil 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey

reply via email to

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