> On Wed, 29 Mar 100, T.E.Dickey wrote: 
>  
> > these issues were brought up last, iirc, in the early fall (except for 
> > the comment about the content of the htmlized cfg file - which has little 
> > to do with making a release useless). 
>  
> Yes, I am aware of the debates whether this should be added at 
> all or not.  That's not my point, I am not trying to reopen those 
> debates.  I not asking for new mechanisms or scripts or the withdrawal 
> of existing ones, but for some content editing (preferably by those 
> who insisted so much on _having_ an organized lynx.cfg overview - 
> What's the point in having it if it's not organized?).  And when's a 
> better time to ask for it than now? 

That's not a problem. I'd like to keep pre-release changes limited to
documentation and bug fixes - no features added/removed.  I've been working
to build/test all of the platforms I have available & have some small
fixes.  But each time I add a fix, that's something else to re-build/test.
 
> > otoh, there's all that bad press relating to the security issues. 
>  
> Well, I wouldn't object if you released the current code as 2.8.3 
> tomorrow and be done with it.  But if there is to be a lengthy 
> pre-release period, you have to expect that problems are brought up... 

I anticipate a 2-3 week pre-release period since that's what was
requested before (and I've not done my taxes yet ;-).  But if it's in
pre-release, we can dispell some of the bad press.
  
> > we're at a good point to validate what we have & decide whether to 
> > go & release it (with corrections as needed), or find that there's 
> > little support for refining the boolean logic of the commandline 
> > options. 
>  
> It doesn't take much "refining".  Just getting rid of the intermediate 
> LYUseDefShoCur and LYUseDefSelPop (set LYShowCursor and LYSelectPopups 
> directly in LYMain.c, as for other flags) should solve the problem for 
> -show_cursor and -popup, at least. 

well, I'm not sure how much change this involves, so I can't agree/disagree.
  
>    Klaus 
>  


-- 
Thomas E. Dickey
[EMAIL PROTECTED]
http://www.clark.net/pub/dickey

Reply via email to