Re: [PATCH 00/12] Support columinized output in tag/branch/ls-files/grep

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

On Fri, Mar 12, 2010 at 4:13 AM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
> Am 10.03.2010 01:27, schrieb Nguyen Thai Ngoc Duy:
>> On 3/9/10, René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
>>>  With "more complicated", do you perhaps mean what GNU ls does, namely
>>>  having non-uniform column widths?  I never consciously noticed that it
>>>  actually goes out of its way to cram as may columns on the screen as
>>>  possible, it just feels so natural. :)
>>
>> That. And aligned grep output like this
>>
>> pclouds@do ~/w/git/builtin $ git grep -n 38
>> count-objects.c  |  35 |                if (cp - ent->d_name != 38)
>> count-objects.c  |  39 |                        memcpy(path + len + 3,
>> ent->d_name, 38);
>> count-objects.c  |  59 |                memcpy(hex+2, ent->d_name, 38);
>> fsck.c           | 405 |                if (strlen(de->d_name) == 38) {
>> gc.c             | 112 |                if (strspn(ent->d_name,
>> "0123456789abcdef") != 38 ||
>> gc.c             | 113 |                    ent->d_name[38] != '\0')
>> prune-packed.c   |  24 |                if (strlen(de->d_name) != 38)
>> prune-packed.c   |  26 |                memcpy(hex+2, de->d_name, 38);
>> prune-packed.c   |  31 |                memcpy(pathname + len, de->d_name, 38);
>> prune.c          |  64 |                if (strlen(de->d_name) == 38) {
>> receive-pack.c   | 588 |        char hdr_arg[38];
>> upload-archive.c |  86 |        char buf[16384];
>
> Hmm, I'm not sure that this columnizing is very useful in this instance.
>  You can more easily compare the line numbers and the indent level of
> the hits, but both pieces of information are only useful in the context
> of the file, so this easier comparison doesn't buy you much.

It's useful when I need to look at the beginning of matched lines.
With current output, all lines are not aligned, so it's hard too see
where lines begin.

> Another possible use might be the list of untracked files shown by
> status and commit, by the way.

Thanks.

>>> I don't see any benefit of an environment variable over config options.
>>
>> Currently we may pass --column=<foo> from a porcelain to "git column
>> --mode=<foo>", <foo> could be column first, or row first, or either
>> with non-uniform columns (not implemented yet). We can also pass other
>> things to "git column". Putting everything in "<foo>" is OK, although
>> looks ugly. In my private tree, I also have "git column
>> --min-rows/--max-items" that forces the columnizer to one column mode
>> if:
>>  - there will be only one or two rows after columnized, too wide
>> screen for example (--min-rows)
>
> Well, I can't imagine when I would want to use this option.  If I'm OK
> with n + 100 items being displayed in x columns, I'd certainly be OK
> with n items being displayed the same way, even if they only take up a
> single row.

It's probably just me. With 279 character-wide terminal, I find it
much easier to look vertically than 16 items on a single row.

>>  - too many lines and the layout has not been fixed, so nothing gets
>> printed (--max-items). Forcing back to one column mode to stop wait
>> time.
>
> Interesting idea, but I'm not sure if I'd want to use it, too.  Best
> effort pretty-printing combines fast output and optimized display at
> first glance.  However, if there are lots of items then the user would
> benefit the most from having them columnized.
>
> If it takes too long to show the first line of output (since the
> columnizer needs to wait for all items to be generated) then the command
> should only columnize on request.

Yeah. That's the idea of "core.columns = auto". If you specify
--[no-]columns on command line, then it must do as you wish. However,
if you set "core.columns = auto" without additional command line
arguments, then it only shows column layout when it's good to do.
-- 
Duy