diff options
author | simonmar <unknown> | 2005-04-22 14:27:15 +0000 |
---|---|---|
committer | simonmar <unknown> | 2005-04-22 14:27:15 +0000 |
commit | 9e1eb7840dab2790b79892a1c33bc40d0ba1a3c5 (patch) | |
tree | 067887ea622be86df3bd15142467ccdda4349611 /TODO | |
parent | a0e1d17806caac72175a4e13ad1978148d8dc13b (diff) |
[haddock @ 2005-04-22 14:27:15 by simonmar]
Add a TODO item
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 24 |
1 files changed, 11 insertions, 13 deletions
@@ -1,6 +1,11 @@ ----------------------------------------------------------------------------- -- bugs +* For a non-home occurrence of an entity, we should point to the home + location in the doc somehow. This would help to distinguish + multiple functions with the same name (eg. we don't know whether + Prelude.catch is Control.Exception.catch vs. System.IO.Error.catch). + * The lexer should handle "...." in doc strings, only recognising it if the contents looks like a module name. @@ -8,8 +13,6 @@ it is required? (see "[Haskell] auto-qualification of identifiers in Haddock"). -* doc --gen-contents and --use-contents - * A module re-export should only reference the target module if the target module is imported without hiding any of its exports (otherwise we should inline just the exported bits). @@ -45,22 +48,17 @@ ----------------------------------------------------------------------------- -- features -* Command-line flag to give the effect of --#ignore-exports on all modules - (request by Chris Ryder, for generating implementation docs.) +* Something equivalent to JavaDoc's @since -* Command-line flags to hide modules (easier for Cabal to use than requiring - #hide directives in the source). +* Source code: various people want to get at the source code from the docs. + * Optionally include source code for a function in its docs? + * Suggestion from Benjamin Pierce: generat separate HTML pages with the + source code, with anchors that you can link to from the docs. + Sounds fairly easy to implement... * Parse and remember {-# SOURCE #-} imports, possibly do something sensible with them? -* In theory there's no reason why we have to only link to modules which - are imported by the current module. This is an artificial - restriction. We might try doing a two-pass strategy: first find out - what everything exports, and then resolve all the links in the - documentation. We could mark some modules as "definitive" destinations - for links to their entities, or even give a priority for each module. - * nested itemized and enumerated lists. * There ought to be a way to include some structure in the "description" |