Re: Futile bug reports?

[Bill Richter]

   > Or even more obvious, the Gcc manual won't do you any good if you
   > don't already know C, and there are only proprietary C books out
   > there.
   
   The GCC manual is a compiler manual, not a programming book.  You
   are comparing apples and oranges here.

I completely agree!!!  RMS's response didn't make  this distinction.
Here's how RMS responded to me: 

       The textbook of a first-year Scheme course, such as SICP or
       HTDP, would then *not* be considered a "manual", so there is no
       policy violation in recommending SICP on g.e.h.

   I would agree that SICP is outside the scope of documentation.  An
   introduction to Scheme would definitely be documentation, though.

RMS is saying that an intro Scheme book is an Emacs manual.  That's
 your apples and oranges.  An intro C book would be a Gcc manual.
  
   > If manuals means books that e.g. compete with the Emacs manual or
   > the Emacs Lisp reference manual, then I'm all for not mentioning
   > such manuals on GNU mailing lists, because these competing
   > manuals cut into sorely needed funds for the FSF.
   
   Now you are talking about apples and apples, with respect to the
   content of the proprietary vs free manuals.
   
I completely agree!!!  

   > I don't see this as an issue of proprietary vs. free books,
   > though.
   
   Well, perhaps you meant to say that you don't agree that one should
   be making an issue of proprietary vs. free books.  

No, I really like the general thrust of RMS's crusade for free books.

   That's your right, but proprietary vs.  free books is precisely the
   issue under discussion in this thread.
 
If RMS wants to say, "no proprietary books will be discussed on
gnusnet", I'll say that's a fine policy, probably counterproductive,
but perfectly coherent.  I just think that the "free manuals" policy
is incoherent, that we're comparing kiwis and mangos.

   > If someone gets interested in Emacs Lisp, I'll tell them they
   > should read a Scheme book like SICP by Abelson or `How to Design
   > Programs' by Felleisen, and then the Emacs Lisp reference manual
   > will make sense to them.  I can't see how anyone could understand
   > the Emacs Lisp reference manual without having prior knowledge of
   > Scheme/Lisp.
   
   Looking at a Scheme book is not necessary.  Looking at a Scheme
   book is not necessary.  I always point them to the Emacs Lisp
   reference manual and lots of example code.

You're right, Kevin, if all you want to do is modify or debug existing
Emacs lisp code.   And that's all an "Emacs manual" should worry
about. 

And I guess I was incoherent.  When I said

   > I can't see how anyone could understand the Emacs Lisp reference
   > manual without having prior knowledge of Scheme/Lisp.

I only meant that no one could understand the discussion of pointers,
in the Emacs Lisp info node "Cons Cells":

   A cons cell is a data object that represents an ordered pair.  It
   holds, or "refers to," two Lisp objects, one labeled as the CAR,
   and the other labeled as the CDR.

That's nonsense, "refers to" is *not* a synonym for "holds".  here's
similar nonsense from the Emacs Lisp info node "Lists as Boxes":

   Each box "refers to", "points to" or "holds" a Lisp object.  (These
   terms are synonymous.)

"points to" is *not* a synonym for "holds"!!!

So all I meant is that after taking a good 1st year course in Scheme,
one would make one's peace with this pointer theology and not be
thrown off by it in the Emacs Lisp manual.

But the important point is that understanding this pointer theology
isn't needed to modify or debug existing Emacs lisp code, so a book
that could clear up this confusion isn't an Emacs manual.