Re: lynx-dev lynx2.8.2dev.25d-cpp.patch.gz

[Vlad Harchev]

On Tue, 11 May 1999, Doug Kaufman wrote:

> On Wed, 12 May 1999, Henry Nelson wrote:
> 
> > I have not suggested the removal of anything in this present thread.
> > I suggest that if something is added, it ought to at least be meaningful
> > and useful to a large majority of users.
> 
> I have been keeping out of this thread since I haven't really had a
> chance to evaluate Vlad's patches, but I must chime in and agree with
> Henry that any new addition to lynx should either:
> 
> 1. Be valuable to the vast majority of users
> 
> 2. Be valuable to some users and configurable so as to not add bloat for
> the other users
> 
> or
> 
> 3. Be valuable to some users and have minimal impact on size or
> efficiency of lynx.

 Sorry, I thought anyone will check this patch. Functionality it provides can
be disabled by defining NO_EXT_LYNXCF in any globally-visible header file -
like userdefs.h (and probably defining this macro can be made by 'configure').
Thou' I'l send a small patch to improve 'disabling' this functionality.
BTW, if support from 'configure' will be implemented, 'makefile' shouldn't
copy those 4 htmls to $(helpdir)/lynxcfg directory if this 'functionality' is
disabled.
 I still purpose to add this patch, may be with ability to disable it by
some switch of 'configure'.
 
> I don't see where duplication of information already present
> is a significant benefit, even if presented in a new way. I am
> certainly against adding files which add to the size of a "minimal"
> installation. If the problem is that some consider the userdef.h files
> and lynx.cfg files arcane, the fix is to rewrite them. In addition to
> playing with the DOS port, I maintain a recent unix lynx binary for
> use by others on my ISP. I put lynx.cfg, lynx_cfg.h and userdefs.h
> in a world-readable directory so that anyone could see how lynx was
> configured, if they so desire. Shouldn't this be enough?
> 
> I appreciate the effort to write scripts to make lynx more friendly to
> users, but I wouldn't want to see this at the expense of portability
> or unnecessary increase in size of files or binary. After all, one of
> the strong points of lynx is that it is lean. For bloated programs
> with bells and whistles, the big two graphical browsers are readily
> available.

 In its current state, this patch is protable. No scripts are invoked to
generate the files.

> I am getting ready to go to a business meeting, so I may not be able
> to follow this thread or contribute to lynx-dev for a week or so. If
> I can, I'll try to get the diffs for dired in the DOS port to the
> list before I go. This still has bugs in the implementation, but is
> probably enough for others to look at and try to fix.
>                                Doug
> __
> Doug Kaufman
> Internet: address@hidden (preferred)
>         address@hidden
> 

 Best regards,
  -Vlad