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.
Another possible use might be the list of untracked files shown by
status and commit, by the way.
>> 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.
> - 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.
René
--
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