Re: [PATCH v6 01/10] ref-filter: introduce 'ref_formatting_state'

[Karthik Nayak <karthik.188@gmail.com>]

On Thu, Jul 30, 2015 at 1:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Actually, I think it is wrong to have this function in the first
> place.  It is a sign that the caller is doing too little before
> calling this function.
>
> If the act of printing an atom uses the formatting state that says
> "next one needs X", then it is responsible to clear that "next one
> needs X" part of the state, as it is the one who consumed that
> state.  E.g. if it used to say "next one needs to be padded to the
> right" before entering print_value(), then the function did that
> "padded output", then the "next one needs to be padded to the
> right" should be cleared inside print_value().
>

Hmm, something like what we did in version 5  I guess.

> And with that arrangement, together with calling emit() with
> formatting state, %(color:blue) can be handled as a normal part of
> the formatting state mechanism.  The pseudo/modifier atom should
> update the state to "Start printing in blue", and either emit() or
> print_value(), whichever is called first, would notice that state,
> does what was requested, and flip that bit down (because we are
> already printing in "blue" so the next output function does not have
> to do the "blue" thing again).

This makes sense, will work on this thanks :)

-- 
Regards,
Karthik Nayak