WIP: render colours in help #539
Conversation
| case object Colors extends HelpFormat { | ||
| override def colorsEnabled: Boolean = true | ||
| } | ||
| case class AutoColors(env: Map[String, String] = sys.env) extends HelpFormat { |
There was a problem hiding this comment.
Neat - was not aware of this!
This could be a method returning a format instead of a format of its own... and I'd prefer to not include sys.env as a default argument, since it's arguably not pure.
| @@ -0,0 +1,27 @@ | |||
| package com.monovore.decline | |||
|
|
|||
| sealed abstract class HelpFormat extends Product with Serializable { | |||
There was a problem hiding this comment.
I'd be tempted to define this on the Help companion so folks can refer to Help.Format and Help.Plain etc., but I don't feel so strongly.
| | | ||
| |A header. | ||
| | | ||
| |Options and flags: | ||
| | --first, -F | ||
| | First option. | ||
| | |
There was a problem hiding this comment.
Can we do this without updating the existing spacing?
There was a problem hiding this comment.
Yep, I just always felt the default is a bit too crowded so thought I'd sneak it in :P Will revert.
There was a problem hiding this comment.
Yeah... I don't know if I disagree on an aesthetic level, but there are a lot of benefits to compactness in this context. (This change on its own makes this section ~50% larger, and now options get more spacing than section headers, which would probably want even more breathing room proportionately...)
| import com.monovore.decline.HelpFormat.Plain | ||
| import com.monovore.decline.HelpFormat.Colors | ||
|
|
||
| private[decline] trait Theme { |
There was a problem hiding this comment.
I don't follow why we need both Theme and HelpFormat - seems like users could pass in a Theme directly. (And if we can get away with fewer concepts, strong preference for that!)
There was a problem hiding this comment.
seems like users could pass in a Theme directly
I treat Theme interface as almost an implementation details - the methods in it are very tightly coupled to the help rendering logic (they're by no means the minimal set of methods required to render something), and I don't think it's beneficial (at this point) to expose this interface to users at all - because it'd increase compatibility surface.
Alternatively I could make it all 1 concept and make every method in Theme private to address the concerns from previous paragraph - but I felt like keeping Theme separate and private is the easiest w.r.t. API surface and flexibility.
There was a problem hiding this comment.
Yeah, it's true that the fact that it's not user-facing does mitigate it to a large extent. Willing to keep it as is for now...
| } | ||
|
|
||
| def optionList(opts: Opts[_]): Option[List[(Opt[_], Boolean)]] = opts match { | ||
| private[decline] case class HelpArgs( |
There was a problem hiding this comment.
Neat! This seems like something with this shape could eventually be cleaned up and made public for some of the fancier help-rendering ideas folks have had (HTML generation, etc.) but leaving it private for now seems like the right call.
Primary goals:
Non-goals: