Closed SirNickolas closed 9 months ago
Attention: 1 lines
in your changes are missing coverage. Please review.
Comparison is base (
e72cb56
) 98.43% compared to head (a60213b
) 98.40%.:exclamation: Current head a60213b differs from pull request most recent head 54f4b8a. Consider uploading reports for the commit 54f4b8a to get more accurate results
Files | Patch % | Lines |
---|---|---|
source/argparse/ansi.d | 98.07% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I thought about making a separate method instead of overloading opCall
(that would simplify StyleImpl
as well), but how do we name it? bold.writeTo(sink, text);
? formatTo
? Something else? Plain write
/format
seem odd to me because it makes more sense to have such methods declared on the sink.
I have a question. Why do we need
StyledText
? As far as I can tell, the only place where it would be beneficial is an overload ofgetUnstyledTextLength(StyledText)
. But… it is not called from anywhere besides its unit test. I tried removingStyledText
, and everything I had to do to deal with it was dropping several.toString()
calls.
TBH I don't remember why it was needed. If you can remove it without affecting public interface - go ahead (ideally in separate PR).
I thought about making a separate method instead of overloading
opCall
(that would simplifyStyleImpl
as well), but how do we name it?bold.writeTo(sink, text);
?formatTo
? Something else? Plainwrite
/format
seem odd to me because it makes more sense to have such methods declared on the sink.
Could you clarify what you want to achieve? If you want to replace opCall
with something then how will this code look like: "argument "~bold.("name")~" is bold"
)?
Realized there is a more flexible approach: turn StyledText
into a range of characters. It’ll definitely go into its own PR; we can discuss in #135 how exactly it should be done. In the meantime, I reverted the addition of new functionality.
TextStyle
stores its sequence as astring
instead ofubyte[]
. Thus it is allocated only once, not on everyopCall
.appender
+std.conv.toChars
are used instead ofto!string
.bold
,italic
, etc.) are cached in global constants.~=
is used instead of~
where possible.Added another overload ofTextStyle.opCall
, which writes to an output range. This allows to build strings with no intermediate allocations (see the last unit test for an example).I have a question. Why do we need
StyledText
? As far as I can tell, the only place where it would be beneficial is an overload ofgetUnstyledTextLength(StyledText)
. But… it is not called from anywhere besides its unit test. I tried removingStyledText
, and everything I had to do to deal with it was dropping several.toString()
calls.