[Top][All Lists]

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

Re: patch (was: Re: lynx-dev LYNXCFG:, LYNXCOMPILEOPTS:)

From: Klaus Weide
Subject: Re: patch (was: Re: lynx-dev LYNXCFG:, LYNXCOMPILEOPTS:)
Date: Mon, 22 Nov 1999 08:17:18 -0600 (CST)

On Mon, 22 Nov 1999, Henry Nelson wrote:

> > > It seems to me that even the developers prefer the output from trace.
> > 
> > It is different kind of information.
> My point was that developers invariably ask for trace output, but rarely
> if ever ask for the LYNXCOMPILEOPTS page.

Well, once there is a conversation established with a bug reporter, it
*does* seem like overkill to all for all that stuff that is on
LYNXCOMPILEOPTS.  So I often ask more specific questions regarding the
reported problem.

But also it's just to inconvenient to ask for LYNXCOMPILEOPTS.  Describe
how to get there.  What if it isn't compiled in (or an old version).
(Well that's before I thought of typing 'g lynxcompileopts:'.)

Also it feels a bit like LYNXCOMPILEOPTS is in a language that only Tom
really understands.  I only recognize parts of the vocabulary.

> > > really want someone to send a copy of that page, I think you
> > > at least ought to suggest a way for them to do that, i.e., mention mailing
> > > from the P)rint Menu.  
> > 
> > Some users know how to do that, some don't.
> That's my point.  Not everyone is running in an environment where they
> can simply cut-n-paste.  It is not realistic to expect someone to type
> all that information, perhaps after first having to jot it all down.

But a large number of lynx users supposedly do know how to forward a page 
as mail.  Those that don't...  won't.  I hope nobody in their right
mind would *think* of writing down all that stuff on paper first...

But, maybe we *are* better off without a bunch of LYNXCOMPILEOPTS pages
mailed to lynx-dev by people who wouldn't know how to do that unless
told on the page itself.  The minimum requirement is knowing how to

> > > Do you really want a bunch of those coming to lynx-dev?
> > 
> > Why not?
> Well, mine is 12 pages long.  A lot of bug reports come in that are
> obviously not of bugs, or are of bugs that have long been fixed.

Yes, but more info also makes it sometimes easy to see that it *is* an
old bug.

I wouldn't expect Larry or you or Philip or... on this list to send
those pages each time they report a problem.

> > > It might be more efficient to ask for the information that is pertinent.
> As usual, I didn't express myself well.  I meant, could LYNXCOMPILEOPTS
> be designed to answer just those questions you really want answered, like
> version, compiler, curses, etc.?  Would it be possible to find a subset
> of compile options _essential_ to any debugging?
> For example, out of:
> RLOGIN_PATH                         "/usr/ucb/rlogin"
> RM_PATH                             "/usr/bin/rm"
> STDC_HEADERS                        1
> SYSTEM_MAIL                         "/usr/lib/sendmail"
> SYSTEM_MAIL_FLAGS                   "-t -oi"
> TAR_PATH                            "/usr/local/bin/tar"
> TELNET_PATH                         "/usr/ucb/telnet"
> TERMIO_AND_CURSES                   1
> TN3270_PATH                         "tn3270"
> TOUCH_PATH                          "/usr/ucb/touch"
> UNCOMPRESS_PATH                     "/usr/local/bin/gunzip"
> UNIX                                1
> UNZIP_PATH                          "/usr/bin/unzip"
> could you get by without the path definitions?  Same question about
> the path_* compile options.  How about func_*, header_*, type_*?

I don't really know...
Usually RM_PATH isn't interesting.  If the problems is "Lynx leaves
temp files behind", then it might be.  Usually TELNET_PATH isn't
interesting.  If the problem is "telnet URLs don't work", then it is.
And so on.

I thing the second part of the page is more interesting.  (Or let's
say it's the only part that would tell me something.  It is what lynx
sees.)  But I assume for Tom the first part (how did configure arrive
at the second part?) *is* interesting.

> I'm asking, not arguing.  I think with a more focused and concise
> LYNXCOMPILEOPTS page, the chances of getting it sent in would improve
> considerably.

Possibly.  (But possibly also the number of cases where it doesn't
contain enough info.)

Anyway - It seems "we" (lynx-dev / don't even have
a current "How to report bugs" page.  (Or do we?  What I find is only
<> which is awfully out
of date.)  So it seems we don't care too much either way...

Perhaps effort would better be spent making *sure* people in "I want
to report a lynx problem" mode will see what they need.


reply via email to

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