How do I print help info with colored command names?

Hello! I'm having trouble finding a solution to this. Is something like this currently possible?

optparse-applicative version: 0.17.0.0

Currently, what I tried to so far -

import Options.Applicative (Parser, (<**>))
import qualified Options.Applicative as O
import qualified Options.Applicative.Help as OH

main :: IO ()
main = pure =<< O.customExecParser (O.prefs O.showHelpOnEmpty) opts
  where
    opts =
      O.info
        (myCommands <**> O.helper)
        ( O.fullDesc <> O.progDesc "")

myCommands :: Parser a
myCommands =
  O.subparser $
    O.command
      "myCommand"
      ( O.info
          O.empty
          (O.progDesc "description here")
      )
      <> O.style OH.green

but I got the "metavar" part of it colored green instead, not myCommand which is what I'm looking for:

[HuwCampbell]

Sorry this isn't possible right now.

[Martinsos]

Ah that is too bad!

Before optparse-applicative, our help looked like this:

but now, with optparse, it looks like this:

It is not terrible, but we had titles for the groups of commands bold, and commands where yellowish, and we would like to keep those styles.

Are there any considerations to add this in the future?
If we wanted to make a PR for it ourselves, could you recommend a place where to start, the direction?

[HuwCampbell]

Yeah.

So one of the things I'm considering is adding semantic annotations to the pretty printer document which are then compiled to ANSI codes.

Thanks for sharing.

[HuwCampbell]

Just a hint, the extra (Command | Command) can be fixed with hidden on one of them.

[Martinsos]

Yeah.

So one of the things I'm considering is adding semantic annotations to the pretty printer document which are then compiled to ANSI codes.

Thanks for sharing.

That sounds interesting.

I was hoping there would be some easy way to provide our own logic for "styling" the help output. For example, I could provide a function that takes subgroup name as an input and returns it stylized (well, surrounded with ANSI codes in my case but could be anything, emojis or something) and then that is used in its place. There would also be a function for command names.

EDIT: I am guessing that might mess up the length calculation for those, which is important for correct indentation / wrapping, but we can solve that by having the function return visual length.

[HuwCampbell]

The way forward is to use a SemanticDoc type internally, which annotates the Doc tree with what each printed item is (like, a command, or optional flag).

The user facing API should stay the same.

Then, the help generator would take those annotations, and convert them to ANSI codes.

I'm happy to consider PRs but I'm also pretty cautious here. Migrating to prettyprinter had some unexpected exponential blow ups.

Things to consider are opting out with the NOCOLOUR environment variable and in via modifiers.

[Martinsos]

So something like:

data HelpPrinterOptions = HelpPrinterOptions {
  showSubgroup :: Text -> (Text, Int),
  showCommandName :: Text -> (Text, Int),
  showCommandUsage :: Text -> (Text, Int)
}

and then I could do something like

HelpPrinterOptions {
  showSubgroup = \subgroupName -> (Term.style [Term.Bold] subgroupName, length subgroupName),
  showCommandName = ...,
  showCommandUsage = \u -> (u, length u)
}

[Martinsos]

The way forward is to use a SemanticDoc type internally, which annotates the Doc tree with what each printed item is (like, a command, or optional flag).

The user facing API should stay the same.

Then, the help generator would take those annotations, and convert them to ANSI codes.

I'm happy to consider PRs but I'm also pretty cautious here. Migrating to prettyprinter had some unexpected exponential blow ups.

Things to consider are opting out with the NOCOLOUR environment variable and in via modifiers.

I don't quite get how the styling would work then -> you would have predefined styles? Could user, via API, define styles for subgroups / commands? If API doesn't change, I don't see how they could?

[HuwCampbell]

There would be a new modifier to override reannotation.

The default would do nothing, but you could, for example, make optional things dull.

[HuwCampbell]

I should have said wouldn't change in a breaking way instead of stay the same.

[Martinsos]

Thanks @HuwCampbell -> I don't quite understand the details of what you described, as I probably don't know enough about optparse yet. I am most interested if this would allow relatively a lot of freedom to style our help usage -> but if I got it right, it would not, and would still be quite limited in what it offers?

I was hoping for such simple interface as the one I described, but I undrestand you had bad experience with pretty printing before. Still, to me it does sound like a feature that couldn't mess up much and would be quite on the edge of the existing logic -> but I don't know anything about the optparse codebase.

Thanks for your time to discuss this, I won't bother you more at the moment as I think the initial goal of sketching out some directions was accomplished.

[HuwCampbell]

Sorry I was on my phone so my responses were a bit brief. I was mostly talking about internals, but I think the end result will allow the sort of customisation you're after.

[Martinsos]

Sorry I was on my phone so my responses were a bit brief. I was mostly talking about internals, but I think the end result will allow the sort of customisation you're after.

Ah ok that does make more sense now! I don't know much about internals so I couldn't make much out of it. Thanks!