finding that flag (and other topic-related flags) might become
easier in future. there is one patch for head that would allow
to query directly for interactive mode (or other topical) flags:
$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --flags
Interactive:
How did I know that the search term I wanted was "Interactive"? I'd
probably try "GHCi" first. How did I know that I have to add that colon at
the end? Yet the user certainly knows how to navigate a web page, or a
text file or man page on Unix. We don't need a GHC-specific user interface
to documentation that needs documenting itself.
$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --flags flags
Flag reference
Help and verbosity options
--flags section:flag | flag reference | mode | -
Which phases to run
..
i was trying to improve my usual problem pattern:
- i suspect there might be a flag to do what i want, but i'm
not sure, and i've no idea what it might be called, so i
can't search for it, either
- on windows systems, releases come with docs
by default, but on unix systems, they are often
not installed
- i suggested the new --print-docdir, to make finding
the local and version-specific docs easier
- when i'm in my vim plugins, i can open the html docs
directly, but i'm looking for something to use while i'm
in cygwin or unix shells, on the commandline
- the flag reference page is rather overwhelming, but
i scroll up and down until i find something that might
be relevant
in my version, i can do 'ghc --flags :' to get the full
flag reference (similar to your suggested and welcome,
but still unimplemented --full-help). but i hardly ever
use that.
instead, i do 'ghc --flags @' to see all section headers,
see that there is a section for 'Interactive-mode options',
say, then do 'ghc --flags Interactive:' to see the flags
in that section, as they are most likely to be relevant;
there, i see some flags called *print*, so i look them up
(or i remember that one of them does what i need).
similarly, i get easy access to options in other sections:
'ghc --flags Profiling:', say, or 'ghc --flags Language:',
etc. or even 'ghc --flags Help:' (which tells me how to
use --flags, among others):
$ /cygdrive/c/fptools/ghc/compiler/stage2/ghc-inplace --flags Help:
Help and verbosity options
Flag | Description | Static/Dynamic | Reverse
-? | help | mode | -
--flags section:flag | flag reference | mode | -
-help | help | mode | -
-n | do a dry run | dynamic | -
-v | verbose mode (equivalent to -v3) | dynamic | -
-vn | set verbosity level | dynamic | -
-V | display GHC version | mode | -
--supported-languages | display the supported language extensions | mode | -
--info | display information about the compiler | mode | -
--version | display GHC version | mode | -
--numeric-version | display GHC version (numeric only) | mode | -
--print-libdir | display GHC library directory | mode | -
--print-docdir | display GHC documentation directory | mode | -
-ferror-spans | output full span in error messages | static | -
-Hsize | Set the minimum heap size to size | static | -
-Rghc-timing | Summarise timing stats for GHC (same as +RTS -tstderr) | static
| -
one could improve the formatting, and it would be better
if a missing parameter would give usage tips (such as the
unfortunately non-obvious '--flags :' and '--flags @'), but
i was trying to get something -anything, really, so --full-help
would have been fine- into 6.8.1.
since gnu decided to abandon man in favour of info,
good commandline help has become more important
(--help in detail, or things like perldoc). making its usage
obvious is important, but first it has to be there and usable.
i don't want to argue lost causes, so let me address
your other objection here as well: cygwin is one of the
first things i install on a new windows machine, so i'm
not harmed either way; as long as you do something
about that ticket, such as implementing --full-help as
giving an ascii-only man-page, i can use 'less'+search.
still, i find --flags much easier to use, especially for
sections and narrowing down to flags of unknown name,
and some of us have been on machines (for teaching
or talks, say) where we couldn't install things; we are
talking about 8 more lines to make life easier for ghc
users, wrt obtaining basic ghc usage information..
claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
