| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Add a proper Haddock module header to each module, with a more finegrained
copyright. If you feel mis-accreditted, please correct any copyright notice!
The maintainer field is set to haddock@projects.haskell.org.
Next step is to add a brief description to each module.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces:
- A page that displays the documentation in a framed view. The left
side will show a full module index. Clicking a module name will
show it in the right frame. If Javascript is enabled, the left
side is split again to show the modules at the top and a very short
synopsis for the module currently displayed on the right.
- Code to generate the mini-synopsis for each module and the mini
module index ("index-frames.html").
- CSS rules for the mini-synopsis.
- A very small amount of javascript to update the mini-synopsis (but
only if inside a frame.)
Some perhaps controversial things:
- Sharing code was very difficult, so there is a small amount of code
duplication.
- The amount of generated pages has been doubled, since every module
now also gets a mini-synopsis. The overhead should not be too
much, but I haven't checked. Alternatively, the mini-synopsis
could also be generated using Javascript if we properly annotate
the actual synopsis.
|
| | |
|
| |
|
|
|
|
| |
The support for DocPic was merged into the GHC source long ago,
but the support in Haddock was forgotten. Thanks Peter Gavin for
submitting this fix!
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ross Paterson reported a bug where links would point to the defining module
instead of the "best" module for an identifier (e.g Int pointing to GHC.Base
instead of Data.Int). This patch fixes this problem by refactoring the way
renamed names are represented. Instead of representing them by:
> data DocName = Link Name | NoLink Name
they are now represented as such:
> data DocName = Documented Name Module | Undocumented Name
and the the link-env looks like this:
> type LinkEnv = Map Name Module
There are several reasons for this. First of all, the bug was caused by
changing the module part of Names during the renaming process, without changing
the Unique field. This caused names to be overwritten during the loading of
.haddock files (which caches names using the NameCache of the GHC session).
So we might create new Uniques during renaming to fix this (but I'm not
sure that would be problem-free). Instead, we just keep the Name and add the
Module where the name is best documented, since it can be useful to keep
the original Name around (for e.g. source-code location info and for users of
the Haddock API).
Also, the names Link/NoLink don't really make sense, since wether to use
links or not is entirely up to the users of DocName.
In the process of following this change into H.Backends.Html I removed the
assumption that binder names are Undocumented (which was just an unnecessary
assumption, the OccName is the only thing needed to render these). This will
probably make it possible to get rid of the renamer and replace it with a
traversal from SYB or Uniplate.
Since DocName has changed, InterfaceFile has changed so this patch also
increments the file-format version. No backwards-compatibility is implemented.
|
| |
|
|
|
|
| |
haddock.js will be run automatically by Windows when you type
'haddock' if it is found on the PATH, so rename to avoid confusion.
Spotted by Adrian Hey.
|
| | |
|
| |
|
|
|
| |
haddock depending on the network causes a circular dependency
at least if you want to build the network lib with haddock docs.
|
| |
|
|
|
|
|
| |
We introduce InstalledInterface capturing the part of Interface that is stored
in the interface files. We change the ppHtmlContents and ppHtmllIndex to take
this structure instead of a partial Interface. We add stuff like the doc map
and exported names to the .haddock file (via InstalledInterface).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
