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.
If the pre-processor is going to turn it into Haskell, then I think it is a fair bet that the majority of the source code will be lexically compatible with Haskell, no matter which pp we are talking about. And in general, the original source will be more readable than the source after processing.
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?
I'm guessing that a particular library author is going to stick with the same style throughout a project, so they could choose to use an option in the .cabal file? hscolour-literate-option: -lit-tex The semantics would be that Cabal adds the "hscolour-literate-option" to the HsColour commandline, only for {.lhs, .ly, .lx} files. If the hscolour-literate-option is not specified, then it defaults to "-lit". (The opposite default would of course be possible - I don't know which style is the majority preference.) Regards, Malcolm