From: Nguyen Thai Ngoc Duy Date: Fri, 12 Mar 2010 04:22:26 GMT Subject: Re: [PATCH 00/12] Support columinized output in tag/branch/ls-files/grep Message-ID: In-Reply-To: <4B995D0C.2090000@lsrfire.ath.cx> On Fri, Mar 12, 2010 at 4:13 AM, René Scharfe wrote: > Am 10.03.2010 01:27, schrieb Nguyen Thai Ngoc Duy: >> On 3/9/10, René Scharfe 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= from a porcelain to "git column >> --mode=", 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 "" 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