RE: [boost] Re: Thoughts on Format

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-29 12:32:27

From:	Brey, Edward D [SMTP:EdwardDBrey_at_[hidden]]
> 
> > From: Stewart, Robert [mailto:stewart_at_[hidden]]
> 
> The central idea is that the width is either in the format string, in
which
> case the translator has carte blanche, or is programmatic, in which case
it
> is always bound tightly to a single parameter (or persisted across all
> subsequent parameters).  There is never a need for change of binding of a
> programmatic width in the format string.

I understand now, and I agree with you.

> > There's no need for tab stops or alignments.  The available 
> > width is divided
> > into regions based upon the number of spring tabs, then the 
> > text is inserted
> > into those regions with specific overflow rules.
> 
> Neat.  The width of the region still needs to be provided, right?  And

Yes.  So, the question becomes how we specify that width, eh?  As I see it,
the spring tabs would apply to the entire formatted output or, more
generally, to all lines in the output.  Thus, we need only specify one width
for the output, as it relates to spring tabs.  That means we need the notion
of a default width, changeable on a per format object basis, and a specifier
that allows setting the width, such as:

    [@:80]@[1]@Example@[2:8.2^~]

which means divide an 80 character field into four equal regions (20
characters each), putting the value of argument 1 in the second region,
"Example" in the third region, and the value of argument 2 in the fourth
region.  Furthermore, the formatting of argument 2, within the fourth region
uses a field width of 8, a precision of 2, centers the value, and uses "~"
as the fill character.

What do you think?

> wouldn't there be some cases where it would be handy to hand-specify the
tab
> locations?  This reminds me of HTML tables.  It also points out a fuzzy
> line: When does format go too far such that it becomes its own mark-up
> language (i.e. Lynx in library format)?

I don't think we should go that far.  You can do a surprisingly varied
amount of formatting with spring tabs.  Anything beyond that would get too
complicated -- one of the things we're trying to eliminate -- and would
certainly encroach on many other methods for rendering text.  Besides, look
at my example above; you don't want to make things any more complicated than
that, do you?

Rob
Susquehanna International Group, LLP
http://www.sig.com