Simon Marlow wrote:
Generating a single unified index is entirely possible, given all the .haddock files for the relevant packages. I'll try to get this into the next version of Haddock.
But only as an option and/or addition, I hope...
If index generation was done as a separate operation using the .haddock file, then you have the option of generating a single index for your package or a unified index for multiple packages. There's then the issue of where the index hyperlinks from the documentation should point to. A command-line flag should suffice for redirecting these in the case when you're going to generate a super-index later on.
2. Remove the split between "type/class index" and "function/constructor index" in the Haddockish doc-index.html file.
Yes, this is also something I'd like to do.
Hmmm, I actually prefer the current situation: If you don't even know if you should look for a type or a function, you probably have more trouble than just two indices... :-]
I'm afraid you're in the minority here, most people would prefer a single index it seems. Isn't it easier to just look in a single index rather than having to think about whether you're looking for a type or function first?
3. Some links in the indexes are bold, others aren't.
The bold ones represent the *original* defining module for the entity, as compared to a module which just re-exports it. However, knowing this information isn't very useful, and arguably it shouldn't be displayed to the user at all. I'll change this for the next Haddock version.
Again, I like the current situation, it saves you the trouble to look into simple "collecting modulues" (doing only imports and re-exports) by giving the user a clue where the documentation is.
The documentation should be at the end of *all* of the index links. But I've just noticed a bug: if an entity is re-exported by 'module M', then it still gets an index entry with a hyperlink for that module. I'll fix that to remove the hyperlink - would that address your complaint? Cheers, Simon