On Mon, 2009-02-09 at 15:36 +0000, Malcolm Wallace wrote: > Duncan Coutts <[email protected]> wrote: > > > Someone was complaining the other day that the hscolour output > > run on the result of happy is not really readable, > > To clarify, what he said was that hscolouring Happy output did not > _enhance_ its readability. In other words, you can put lipstick on a > pig, but it's still a pig.
Yep :-) > > but then it's not > > clear if running it on the happy input would be any better. > > Try it! I reckon it looks pretty good actually. Lexically, the > difference between Happy and H'98 sources is negligible. Aye. The difficulty is we have to have a list of which pre-processors to run or not run before using hscolour. Or perhaps we just hope that all original sources are ok going through hscolour, even if they're not Haskell. > > For the particular case of .lhs and cpp, I hope we'd get better > > hscolour output by not running unlit or cpp first. Malcolm says it'll > > at least do something. So it seems worth checking which ends up > > looking more useful. > > It seems likely that preserving the literate comments is the sensible > thing to do, since we are linking together documentation here > (haddock/source). HsColour has -lit and -lit-tex options, to avoid > colouring the literate comments from a .lhs. I'm not sure what we can do here. We don't know if the file is bird track or tex style. Can we get away with always using one option? Duncan _______________________________________________ cabal-devel mailing list [email protected] http://www.haskell.org/mailman/listinfo/cabal-devel
