On Fri, Mar 12, 2010 at 4:13 AM, René Scharfe
<rene.scharfe@xxxxxxxxxxxxxx> wrote:
> Am 10.03.2010 01:27, schrieb Nguyen Thai Ngoc Duy:
>> On 3/9/10, René Scharfe <rene.scharfe@xxxxxxxxxxxxxx> 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
--
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