On Thu, Sep 20, 2012 at 11:40 PM, Junio C Hamano <gitster@xxxxxxxxx> 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 --oneline? > - 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 > computed? 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 > patch: > > 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. -- Duy -- 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