On Sat, 18 Jun 2016 07:36:02 +0200, Hervé BOUTEMY <herve.bout...@free.fr> wrote:

Le vendredi 17 juin 2016 09:39:45 Robert Scholte a écrit :
Hi,

a few remarks to the API ( I like the idea of it ).
- use strong() instead of highlight()
ok for this one

- use text() instead of a()
I'd prefer to stay with the good JANsi idea: a is short, and represent
"append" in a text buffer.


So it i a matter of taste. I'd prefer a method name which makes sense. How about also having append(Object) which does exactly the same, so it is up to the user which method they prefer.

Do we want to be able to nest styles (or mimic it)?
e.g *strong* please ensure to replace this method before *warn* 1-1-2017
*_warn* !!! *_bold*
If so, we'd better use matching closing methods, like we do with Doxia Sink
no, no nesting styles: there is reset() to reset

If there's no intention to nest, then there's also no reason to have a reset()-method in the API.
Instead pass the argument on which you want to apply the style, e.g.
strong( "This is a strong text" ).a( " and this is plain again." )

With autoboxing it is probably easier only have one Object argument instead of having methods for every primitive


JANSI api shouldn't be leading, but what we think is general enough for
every ANSI implementation
JAnsi API is just a good idea to match ANSI capabilities
I'd say that an API done for rendering HTML should not be leading ANSI
rendering, since the capabilities are really different


thanks,
thanks for ideas and discussion: this is a area we have to discover

Robert

On Fri, 17 Jun 2016 08:08:54 +0200, Hervé BOUTEMY <herve.bout...@free.fr>

wrote:
> there are concepts: that's what the API I propose expose [1]
> Name of the different colors can still be refined, I had to find a first
> naming
>
> if nobody objets, I'll update Maven core and maven-invoker-plugin with
> this
> API like I already did in maven-site-plugin [2]
> And I think I should be able to implement configuration in settings.xml
> (probably not the final version, but a first implementation that will
> permit
> us easy color schemes testing)
>
> Regards,
>
> Hervé
>
> [1] http://svn.apache.org/viewvc?rev=1748766&view=rev
>
> [2] http://svn.apache.org/viewvc?rev=1748768&view=rev
>
> Le jeudi 16 juin 2016 22:15:20 Christian Schulte a écrit :
>> Am 06/16/16 um 22:00 schrieb Gary Gregory:
>> > On Thu, Jun 16, 2016 at 12:55 PM, Christian Schulte <c...@schulte.it>
>>
>> wrote:
>> >> Am 06/16/16 um 21:07 schrieb Hervé BOUTEMY:
>> >>> the second commit makes really things awful here
>> >>> Sorry, -1, please revert
>> >>
>> >> I just reverted both commits. To me it's not clear what the benefit
>>
>> of
>>
>> >> colored log messages should be. Having errors in red and warnings in >> >> yellow (not just the log level name - the whole message) would make
>> >> sense as it has an eye-catching effect. Everything else is just
>>
>> eyecandy
>>
>> >> without any real benefit even reducing that eye-catching effect.
>> >
>> > I disagree. Look how nice Git's color console output is (compared to
>>
>> all
>>
>> > one color)
>> >
>> > Gary
>>
>> See the screenshots. GIT appears to have some kind of concept behind
>> what colour is used for what and when. Compare that to current master.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Reply via email to