On Thu, Jul 30, 2015 at 1:24 AM, Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html