> -----Original Message-----
> From: Philipp Marek [mailto:philipp.marek_at_emerion.com]
> Sent: maandag 12 april 2010 14:43
> To: Hyrum K. Wright
> Cc: dev; Erik Huelsmann; Stefan Sperling; Johan Corveleyn
> Subject: Re: misaligned blame output if repo has >1m revisions
> Hello Hyrum!
> On Montag, 12. April 2010, Hyrum K. Wright wrote:
> > On Mon, Apr 12, 2010 at 11:01 AM, Philipp Marek
> > > So 9 digits should buy a bit of time ;-)
> > Sure, but the more digits you put in, the more stuff gets pushed off the
> > back of the line. On a 80-character terminal, with code that's 79
> > characters long, parsing blame output is difficult enough as it is;
> > more space just seems like it would make the problem harder, and is only
> > required in a handful of cases.
> a) even the linux kernel hackers aren't really strict about 80 columns;
> b) if you have more than 40 whitespace characters at the beginning of a
> you can either set your tab-stops smaller, or at least scroll
> to look for the line
> c) cutting the revision number or, as you say, the user, only creates a
Well, on Windows consoles are all 80 characters wide. (You can fix this if
you are a frequent Command Prompt User, but most applications just assume 80
characters on Windows. And in many cases Windows switches back to 80
characters if it detects direct screen operations)
The tab width is not globally configurable on Windows.
> > And we still have the problem of too-long user names (such as
> > in our own repo).
> Well, my use-case is normally "why did this line change?" - and on a blame
> output I can easily go to the same line, too see the revision.
> So the width of the terminal is normally not interesting for me here.
> Depending on your editor you could define a vertical fold, or have the
> revision/user in a status line or mouse popup, or whatever - then the
> additional space is of no concern. Only the full data, not cut off, must
> Of course, if the needed number of characters for revision and user is
> found during traversal, so much the better.
We have all these values in memory during traversal so calculating it
shouldn't be a performance issue.
Received on 2010-04-12 15:02:41 CEST