This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gfortran.info: index


Daniel Franke wrote:
currently, the index of gfortran.info is quite hard to use. TexInfo provides different kinds of indices per default: a "Concept Index", a "Function Index" and others we probably don't need.

I'd like to split the current all-in-one concept index into two parts: concept and function index. The function index shall hold all the entries currently defined as:

before: @cindex @code{XY} intrinsic
after: @findex XY


(findex uses @code-style by default)

If you look in the archives, you'll find where I combined them, about a year ago. :)


Actually, on second thought, I didn't actually combine them -- I just converted all the @findex entries to @cindex ones, since they were all being put in the same index at the end anyway.

At the time, part of my reasoning was that they were all going in the same index anyway (and they were all phrased as "XY intrinsic", so the "intrinsic" part was misformatted in "code" format), but the other part was that since all the intrinsic functions were in the same place in alphabetical order so an index didn't really seem useful.

With your proposed idea of reordering the intrinsics into groups (and I think that's quite a good idea), the index of intrinsics becomes useful again. Though probably it will be an index of intrinsics and other keywords, and should be titled as such.

Also, gfortran.texi:11 defines "a separate index for command line options", whose entries would be generated by @opindex. There is not a single occurence of @opindex in the gfortran docs. Was this meant to be added, or is this an artifact of an earlier attempt to structure the index?

I have no idea; it was before my time.


Any objections against the proposed split of indices?

Nope -- to repeat the above in shorter form, I'm in favor of it.


How about an additional index for command line options?

The command-line option index might also be useful, though are there enough cases where the options are mentioned outside the "options" section to make it worth it?


- Brooks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]