hsman

[Frederik Eaton]

> Yes, I know command line completion works - but only for files, not
> for anything else, and there is no way to make it work for other
> things. However, I know that zsh can do funky things like
> autocompleting ssh paths etc - and I think I remember seeing that
> there was some way a program could tell zsh what it could autocomplete
> to - but that is a hazy memory from a while ago.

What I did, to make things more modular, was add an option to my
program to list the completions of a given set of arguments. So
prepending "--completions" to the argument list and running the
program just prints out a list of completions for the last argument. 
It's not really correct, since the user might have backed up to e.g. 
the second-to-last argument and pressed TAB there, but I'm not sure
how to fix it. It's probably a simple modification, that a real zsh
person could figure out in a second. I have a file containing the
following in my fpath:

----------------------------------------------------------------
#!/bin/zsh

_haskell-man () {
    L=($($words[0] --completions $words))
    compadd -a -- L
}

compdef _haskell-man hsman
----------------------------------------------------------------

Anyway, you say you are working on a command line interface - OK, but
I think the current situation is just a bit embarrassing, and I have
something that works now. I can access all Perl documentation with
'man', and that is very convenient. It is just two words, e.g.:

$ man CGI

I think it is reasonable to expect any other kind of documentation to
be just as easy to look up. I think a satisfactory system for Haskell
should:

- be usable from the command line, and with tab completion (i.e. users
shouldn't have to enter an interactive loop like ghci)

- be able to show the haddock documentation for a given function (the
most common usage) in one step (i.e. not 2 steps as with the hoogle
web interface). when there is more than one match, my program chooses
a default; the user can ask to see all matches with a separate option. 
this is usually preferable, because many functions, for instance
foldl1, are defined in multiple places with exactly the same
documentation (Prelude, Data.List, Data.Foldable), and the user
doesn't care which one pops up.

Best,

Frederik

-- 
http://ofb.net/~frederik/