I noticed that this pattern repeats itself:

let (draw_fn, pad, style) = draw::get_draw_function();

draw_fn(pad, style, ...);

The get returns a function/closure and parameters for it, so those are (directly or indirectly) fed back into it. Instead the returned closure should already handle these, then the if pad { .. } else { .. } is only inside the closure, and decoration_ansi_term_style doesn't make this strange round-trip.

Also, type DrawFunction doesn't have to be a dyn FnMut, just dyn Fn. However, the padding in merge_conflict.rs would also get applied to derived_commit_name, but maybe this visually doesn't make a difference.

@th1000s I have just submitted a commit to fix the strange round-trip :)

Thanks! Can you split the concat!() fix into a separate commit?

The match decoration_style { ... } can be made shorter by returning (write_boxed*, style). These write functions are just of type fn(...) -> Result<()>, so no boxing is needed. Then the padding-if-else and calling can all happen in one place, not in every match arm (and then padding could be done for every case).

Also, avoid double negatives, e.g. never_pad = false. In fact, add an enum for that, PadText::{Yes, No}, and place it right after the two text arguments which are padded. Then the purpose of this argument is clear, even without inlay hints.