Re: [Haskell-cafe] Re: Writing great documentation[MESSAGE NOT SCANNED]
I agree with Duncan's comment:
I rather like the idea of using markdown (pandoc) for separate
non-reference docs like man pages, tutorials, user guides etc rather
than trying to make haddock do everything.
In one of my projects (Hydra and Sigma), I use pandoc for the bulk of
the documentation, and integrate this with haddock documentation for the
parts of the documentation that haddock can do (which is a small part of
it). This is all coordinated by a (rather clunky) Setup.hs. The whole
thing isn't very elegant, but it works robustly on both Linux and
Windows. That's a big advantage of pandoc: you can install it with
cabal and use it in your Setup, so it isn't necessary to do any shell
scripting, which can cause portability problems. I'll attach the
Setup.hs file.
One of the central issues here is *where* the documentation files go. I
don't like the existing situation, where haddock documentation goes into
a standard place, and presumably other documentation goes somewhere
else. It's surely better to have all the documentation for a package in
one directory, with all the parts linked together. So my setup makes a
directory, builds the haddock and pandoc pieces of the documentation,
copies (or build) it all into the directory, and then the contents of
this directory is listed under data-files in the cabal file. The result
is that building the system produces a complete self-contained directory
and the executable application is able to find its own documentation
files. This is usful in a GUI program, for example, where it's nice to
make the documentation availble under the Help menu.
Something along these lines (with a cleaner design) would be generally
useful.
John O'Donnell
On 11/13/2009 10:31 PM, Duncan Coutts wrote:
On Fri, 2009-11-13 at 23:20 +0200, Max Rabkin wrote:
On Fri, Nov 13, 2009 at 10:58 PM, Simon Michael wrote:
A very common problem with online docs is fragmentation.
Absolutely! Is it possible to include non-haddock documentation in a
cabal package. Is it possible to have it readable on Hackage?
Not yet.
Want to volunteer?
http://hackage.haskell.org/trac/hackage/ticket/330
It's partly a matter of tasteful design and partly implementation. The
same person/people do not need to do both bits. Thrashing out a detailed
and workable design would get us most of the way there.
I think this would help with the fragmentation and versioning issues.
Yes, I agree.
One option is to have haddock-only modules for non-reference
documentation (xmonad-contrib does this), and I think at the moment it
is a good option, but it does have disadvantages. It may not be clear
from the outline where documentation can be found, and it clutters up
the module namespace. Perhaps we could add support for a
Documentation-Modules field in cabal files, which would separate these
modules in the outline, and not install them but only their
documentation.
I rather like the idea of using markdown (pandoc) for separate
non-reference docs like man pages, tutorials, user guides etc rather
than trying to make haddock do everything.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
import Distribution.Simple
import System.Directory
import System.FilePath
import Text.Pandoc
import Text.Pandoc.Shared
import qualified System.IO.UTF8 as U
-- To do:
main = defaultMainWithHooks hooks
hooks :: UserHooks
hooks = simpleUserHooks {postBuild = postBuildHook}
{- Haddock creates its documentation in the form of a set of files in
dist/doc/html/Hydra. These files have names matching *.html, *.gif,
*.css, *.js, Hydra.haddock. After running haddock, we have:
dist/doc/html/Hydra/(files created by Haddock)
Hydra has much more extensive documentation, produced by pandoc from
sources in doc. The top level file in this is index.html. To avoid
conflicts between the primary Hydra documentation and the API
documentation from haddock, the following steps are taken:
1. A list of files in dist/doc/html/Hydra/ is created,
and named haddock_files
2. A directory dist/doc/html/Hydra/haddock is created
3. All the files in dist/doc/html/Hydra[haddock_files] are copied to
dist/doc/html/Hydra/haddock
4. All the files in dist/doc/html/Hydra[haddock_files] are removed
5. Pandoc is run on the documentation source files, with the results
placed in dist/doc/html/Hydra. These files contain relative
pointers (URLs) into the haddock documentation.
The result is a documentation directory in the same place Cabal
expects to find it --- dist/doc/html/Hydra --- which contains the
Hydra documentation as well as the API reference produced by haddock.
-}
{- The csslink string is html to be incorporated into the pa
[Haskell-cafe] Re: Writing great documentation
On Fri, 13 Nov 2009 22:31:54 + >> "Duncan" == Duncan Coutts wrote: Duncan> I rather like the idea of using markdown (pandoc) for separate Duncan> non-reference docs like man pages, tutorials, user guides etc Duncan> rather than trying to make haddock do everything. I'd agree only with the exception to use rst/docutils/sphinx which produces nice html/pdf. (Yeah, I know it's not Haskell, but...) Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing great documentation
On Fri, 2009-11-13 at 23:20 +0200, Max Rabkin wrote: > On Fri, Nov 13, 2009 at 10:58 PM, Simon Michael wrote: > > A very common problem with online docs is fragmentation. > > Absolutely! Is it possible to include non-haddock documentation in a > cabal package. Is it possible to have it readable on Hackage? Not yet. Want to volunteer? http://hackage.haskell.org/trac/hackage/ticket/330 It's partly a matter of tasteful design and partly implementation. The same person/people do not need to do both bits. Thrashing out a detailed and workable design would get us most of the way there. > I think this would help with the fragmentation and versioning issues. Yes, I agree. > One option is to have haddock-only modules for non-reference > documentation (xmonad-contrib does this), and I think at the moment it > is a good option, but it does have disadvantages. It may not be clear > from the outline where documentation can be found, and it clutters up > the module namespace. Perhaps we could add support for a > Documentation-Modules field in cabal files, which would separate these > modules in the outline, and not install them but only their > documentation. I rather like the idea of using markdown (pandoc) for separate non-reference docs like man pages, tutorials, user guides etc rather than trying to make haddock do everything. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing great documentation
On 13/11/09 21:20, Max Rabkin wrote: > On Fri, Nov 13, 2009 at 10:58 PM, Simon Michael wrote: >> A very common problem with online docs is fragmentation. > > Absolutely! Is it possible to include non-haddock documentation in a > cabal package. Is it possible to have it readable on Hackage? I think > this would help with the fragmentation and versioning issues. > > One option is to have haddock-only modules for non-reference > documentation (xmonad-contrib does this), and I think at the moment it > is a good option, but it does have disadvantages. It may not be clear > from the outline where documentation can be found, and it clutters up > the module namespace. Perhaps we could add support for a > Documentation-Modules field in cabal files, which would separate these > modules in the outline, and not install them but only their > documentation. I feel the Haskell Wiki is a great place to keep non-reference docs. That's what I opted to do for dataenc, and will most likely do if I ever get around to putting other modules on hackage. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Writing great documentation
On Fri, Nov 13, 2009 at 10:58 PM, Simon Michael wrote: > A very common problem with online docs is fragmentation. Absolutely! Is it possible to include non-haddock documentation in a cabal package. Is it possible to have it readable on Hackage? I think this would help with the fragmentation and versioning issues. One option is to have haddock-only modules for non-reference documentation (xmonad-contrib does this), and I think at the moment it is a good option, but it does have disadvantages. It may not be clear from the outline where documentation can be found, and it clutters up the module namespace. Perhaps we could add support for a Documentation-Modules field in cabal files, which would separate these modules in the outline, and not install them but only their documentation. --Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Writing great documentation
Thanks for this topic and the link; I'm going to try to use it to improve the docs for hledger and my other projects. (And I agree, he's wrong about auto-generated docs.) I seem to remember admiring Parsec's documentation. Though, that reminds me.. A very common problem with online docs is fragmentation. Eg, often to learn haskell libraries the reader has to visit multiple sites, or multiple locations and formats from one site, and sort through multiple versions of the docs, to piece together a full picture. You may have the original outdated but most complete docs; the newer, less complete version hosted on haskell.org; the similar but different version pasted on the haskell wiki with discussion; the clarifying (or not) blog articles; the api docs on hackage corresponding to your installed software, etc. To avoid this, I think project leaders need to (a) maintain and clearly identify one canonical starting point for docs (I favour the hackage page for small projects, a dedicated site or a page on the wiki for larger ones); and (b) continually seek out, purge and delete out-dated/inconsistent/duplicated docs wherever they be hosted - get them off the net. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
