Re: [Patch, fortran] Typo and grammatical fixes in intrinsic.texi (repost)

[Brooks Moses <bmoses at stanford dot edu>]

Steve Kargl wrote:
> On Wed, Aug 23, 2006 at 05:46:48PM -0700, Brooks Moses wrote:
> > :ADDPATCH fortran:
> >
> > In looking over Daniel Franke's recent intrinsic.texi patch, I noticed a
> > few typos and small errors that were in the original file.
>
> Just to be clear, do I apply Daniel's patch then apply your
> patch?  Or, is your patch a composite of Daniel's patch and
> your corrections?

Neither; this patch does not contain Daniel's patch, and it would apply 
to the current (unpatched) version of the file.  (Thus, it does not 
contain my suggested corrections to Daniel's patch that I posted earlier.)

Hmm -- I had thought that Daniel's patch would still apply correctly on 
top of mine, but I now see that it doesn't.  Perhaps it would be better 
to wait until he produces a revised/corrected version of his patch and 
then I can do an updated version of this one to apply after it.

Or, alternately, if it would be easier, I could produce a composite 
patch that includes Daniel's patch, my corrections to his patch, and 
this patch of corrections to the original file.

> > I do have a question for future corrections: in the examples of
> > procedure calls, where should spaces be inserted?  Should we have (for
> > instance) @code(C = FUN(X,Y[,Z[,KIND]])}, or @code{C = FUN(X, Y, [, Z [,
> > KIND]])}, or spaces only some of those places, or...?
>
> I'd go with the first.  When the file is processed to generate
> the dvi file, tex will do the kerning for us.

Sounds good.  Though it's worth noting that, since @code{} items are 
typeset verbatim in typewriter font, tex typesets this as written with 
the spaces (or lack thereof) exactly as in the source file.

> > Also, in the
> > "Syntax" entries, should we have discrete examples for each allowable
> > argument combination, or is []-notation allowable there?  In both of
> > these cases, the existing documentation is inconsistent.
>
> For the more complicated intrinsics such as TRANSFER and ASSOCIATED,
> we may want to give more than one example; whereas the simpler intrinsics
> such as SIN and RANDOM_SEED do not need elaborate examples.

Ok.  I can