Re: [PATCH v6 0/10] port tag.c to use ref-filter APIs

On Tuesday, July 28, 2015, Karthik Nayak [off-list ref] wrote:

Changes in v6:
* Change the flow of commits, introduce rest_formatting_state.
* Rename
ref_formatting -> apply_formatting_state
apply_pseudo_state -> store_formatting_state
* Remove the patch for making color a pseudo atom, and rename
pseudo_atom to modifier_atom.
* Small grammatical changes.

Side Note: --format="%(padright:X)" applies to the next available atom
and not to the next span. I find this more accurate as I don't see why
we'd want to pad something of known length. But its up for discussion

This isn't supported by the current %(padright:) syntax, but an
example would be if someone wants to pad a string composed of atoms
and literal strings. For instance, the user might want to right-pad
the composed string "%(refattribute1) glorked %(refattribute2)”.

One possible syntax to support this sort of thing would be
%(padright:n:content). For instance, using the example above:

    %(padright:20:%(refattribute1) glorked %(refattribute2))

Another would be %(padright:n)content%(end). The %(end) token could
work with other formatting directives, such as left padding,
alignment, etc. For instance:

    %(padright:20)%(refattribute1) glorked %(refattribute2)%(end)

In fact, this sort of thing has come up multiple times, with the most
general being actual embedding of a full-blown scripting language to
support pretty much any desired formatting. Other less ambitious
proposals have also been suggested.

This isn't a suggestion that you should implement any of these, but
just a heads-up that, when it comes to formatting, it's not at all
uncommon for people to come up with needs not anticipated by the
design.