On Thu, Sep 20, 2012 at 11:40 PM, Junio C Hamano <gits...@pobox.com> wrote:
> I think this is a great feature at the conceptual level, and you
> know "but" is coming ;-).
I'm still not sure if it's useful beyond my simple example. For
example, will it be useful in multiline log format, not just
> - Shouldn't it be "everything from there until the end of the
> current line" than "everything after that"?
The patch does that. I wasn't specific in my patch description.
> - How is the display width determined and is it fixed once it gets
term_columns(). But I'd rather have a (user-configurable) max limit.
It's really hard to line up two distant text parts of a 200 char line
without a physical ruler. In my patch I just hard code the max limit
around 120 char or so.
> - How does this interact with the wrapped output? Should it?
We have to deal with it anyway when the left aligned text takes all
the space. On one hand, I don't want to break the terminal width,
leading to ugly output, so it'll interact. On the other hand, I don't
really wish to turn pretty format machinery into a full feature text
layout engine (by ripping of links/lynx?). So we have a few options:
1. ellipses, line cutting means i18n issues ahead
2. just put the right-aligned text on another line. We do something
similar in parse-options. When the option syntax is too long, we put
help description on the next line.
3. bring in html/css box model for arranging text so that both
left/right aligned texts can share the same line.
4. tell users upfront it's not supported. don't do that
I'd vote 2, or 4.
> - I am wondering if somebody ever want to do this with a follow-up
> Left %h%|Center %cd%|Right %ad
> Is %| a sensible choice for "flush right"? I am wondering if it
> makes more sense to make %|, %< and %> as "multi-column
> introducer" (the example defines output with three columns) that
> also tells how text inside each column is flushed inside the
> column, e.g.
> %>col 1 right flushed%|col 2 centered%< col 3 left flushed
> or something like that (we may want explicit "column width"
> specifiers if we were to do this kind of thing).
Yeah that crossed my mind. But I'll need to convince myself it's
actually useful. Once you're on that road, you may want >=4 column
tables. We can extend column.c to do that. That hard part is
converting pretty format to use column functions.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html