Re: lynx-dev some proposed nit fixes in lynx.cfg

[David Combs]

I would LOVE to get involved in this discussion -- although
I have somehow missed the initial posts.

My favorite book on the subject is Fowler's "Modern English Usage" --
NOT the new version that came out last year, but any of the prior
ones, which because of complaints from readers, the most recent of
those prior editions are being sold alongside the newer one (much
munged-over by some new guy).  (I myself have not gone through this
newest one, but what from I hear, "everyone" hates it).


Every time you talk about an issue in this lynx.cfg, please also
mention the subject heading IN that file, so I can FIND the text.

Also, I just a few days downloaded a couple of lynxes:

* -rw-r-----   1 dkc      staff    1519943 Nov  3 10:37 lynx2-8-1.tar.gz
* -rw-r-----   1 dkc      staff    1764732 Nov  3 10:32 
lynx2-8-1-rel2-intl.tar.gz

Which one should I look in?  Or do you already have one newer?


> From address@hidden Sat Nov  7 18:52:37 1998
> Date: Sat, 7 Nov 1998 18:51:47 -0800 (PST)
> From: Doug Kaufman <address@hidden>
> 
> On Sat, 7 Nov 1998, Larry W. Virden wrote:
> 
> > > > -# trailing white space will be trimmed, and a single space added by 
> > > > Lynx
> > > > +# trailing white space will be trimmed, and a single space is added by 
> > > > Lynx
> > > > ...
> > 
> > I disagree that was correct originally.

OK, a question about a question or point: should there ve a semicolon after the
"I disagree", or an "it" after the "that".  Makes all the difference.
> 
> This is parallel structure, expanding to "trailing white space will be
> trimmed, and a single space will be added by Lynx". Your change loses
> the structure, with the first part in future tense, and the second part
> present.
How about "... will be removed, and replaced by [only] a single space".

(If you are worried about words, "trimmed" applied to characters is
a computer-related usage -- rather, a computer-PROGRAMMING-related usage.
My own belief is to hell with the user, use the right word, but that's
not very user-friendly.  I would say therefore:

  We programmers who maintain this program talk back and forth to each
   other, with maybe 100 emails broadcast the whole group of hundreds of
   each day, and we use a standard set of computer (programming) terminology.
   Also, most people who read THIS file, lynx.cfg, are "administrators"
   at sites that provide Lynx to their users, and by definition they twoo
   are programmers.

   However, for those of you who are not familiar with the terminology, please
   look at the bottom of this file and see the glossary we have there.

Within that glossary you have words like trim, prepend (there is no better word,
which is why the word had to be coined (oops: for the non-English-speaking,
invented), ...

Thus, a directory is a directory, NOT (god dam# Sun trying to be 
user-UNfriendly)
"folder")


> 
> > 
> > > > -# their actual URL's.  See the sample jumps files in the samples
> > > > +# their actual URL's.  See the jumps files in the lynx*/samples
> > 
> > In this case, URL's should be URLs.  Sorry - I started to make that change
> > (as well as a pass thru fixing all the incorrect uses of it's) and got
> > sidetracked by the kids needing to leave.  I also disagree that saying
> > sample jumps files in the samples directory is better than saying the
> > jumps files in the lynx*/samples directory.
> 
> The reason I liked the original was that it indicated specifically that
> the file was a sample file (i.e. to be changed by the user) and was in
> the samples subdirectory. I suspect that many users wouldn't understand
> that "lynx*/samples" refers to "lynx2-8-1/samples". This requires at least
> simple knowledge of regular expressions, which may be too much to ask.
> 
> > 
> > > > ...
> > > > -# Additional, alternate jumps files can be defined and mapped to
> > > > +# Additional alternate jumps files can be defined and mapped to
> > 
> > My college English book indicated the comma in this case was a coin toss...
> 
> These are both acceptable, but mean different things. The first talks
> about additional files which can be alternate jumps files. The latter
> about more alternate jumps files (implying at least one alternate jumps
> file already in existence).
> 
How about "Alternate and/or alternate jumps-files may be defined"?

(Yeah, I know the books hate and/or, but what else is there that says what
you mean.  The lawbooks talk at length (I can't spell "adnauseum" correctly)
about "or", ie ior vs xor (or as the lawyers might say, ior v xor -- hey,
that  "V", doesn't look so bad, does it, pretty symbolic), or what a comma
means -- judges make it mean whatever they want it to mean for the case to
come out the way they want it to come out!)


> > 
> > > > -# CHARACTER_SET defines the display character set, i.e., that assumed 
> > > > to be
> > > > +# CHARACTER_SET defines the display character set, i.e., assumed to be
> > 
> > I can't fathom how that "that" can be correct.
I cannot see the rest of it, only what's here in the email, but
maybe remove the i.e. (I myself use ie, no periods, but everyone screams
at that, and I know they're right and I'm wrong) can be removed
and changed to "... set (assumed to be EBCDIC)". :-)
> 
> This is actually quite correct. There is an implied antecedent,
> "character set", so this expands to "that character set assumed to be"
> 
> > > I think that this might be better as "It must be specified relative to
> > > the user's home directory"
> > 
> > That's how I started to write it - but I had just worked thru the META 
> > CHARSET
> > section and thought using the words prepended might be a bit easy for the
> > novice reader to figure out than the idea of relative pathnames.  Either
> > way works fine for me.
> 
> My thought was that the word "prepend" is an unusual term that would
> send many users to the dictionary. 

Again, a glossary solves this one.  Prepend is a perfectly good word
when one is talking about parsing html or any other char-processing
app.  
> 
> I think that this may be enough discussion of fine points of English
> usage. The key is to make the document as clear and unambiguous as
> possible to the novice user, while keeping the technical information
> needed by those more experienced. It doesn't have to be grammatically
> correct as long as users can understand what we mean.

I disagree.  It is far too much fun to talk about this, and it is actually
useful.  Further, in going through it, we will have to THINK a bit
about what a given option ACTUALLY MEANS, which can't be a bad thing
every few years.

If others don't want this stuff coming to you, maybe we could create
a semi-private mailing list, maybe even just a local list of names we send
to,   Something in .mailrc (local) that we can fire off to, that gets
to all interested.
>                             Doug
> 
> __
> Doug Kaufman
> Internet: address@hidden (preferred)
>         address@hidden
> 
>