Generating a single unified index is entirely possible, given all the .haddock files for the relevant packages. I'll try to get
Simon Marlow wrote: 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