Re: [PATCH 0/8 v6] diff --stat: use the full terminal width

From: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Date: Feb 22, 2012, 11:24 UTC
Message-ID: <4F44D084.7030308@in.waw.pl>
In-Reply-To: <7v1upogd6w.fsf@alter.siamese.dyndns.org>

On 02/21/2012 09:10 PM, Junio C Hamano wrote:

Show 19 quoted lines

> Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl>  writes:
>
>> This seem overly complex. A nice property to have would be
>> "if the window is wide enough so there's enough space for full
>> filenames, the graph part scales monotonically with the change count".
>> (If there's filename truncation, than there just isn't enough space
>> for everything and the graph may be compressed. But otherwise, if we
>> have two graphs which do not end at the edge of the screen, and the
>> second one is wider than the first one, then without looking at the
>> change counts we know that the second one has more changes).
>>
>> For this property to be satisfied, the graph_width limit would have to
>> be independent of the filename width.
>>
>> So maybe it should be ...
>
> Sorry, the desired property I would understand, but that does not click
> with your "have to be independent" conclusion, so I do not have comment on
> the "maybe it should be..." part.

Hi,

by "scales monotonically with the change count" I meant with two 
different commits. Image that there are two commits
   a | 300 ++++++++++++++++++++++
and
   a/a/a/b | 300 ++++++++++++++++++++++
Both commits have the same change count, but filenames of different 
length. If the filename length can influence the number of "+" in the 
graph, then the scaling is not monotonic. There would always be cases 
when a bigger change with longer filenames has a narrower graph.

Show 13 quoted lines

> The resolution requirement may want to set a "desired lower limit" for the
> width of the graph, but it is only "desired" because it is possible that
> you have to bust the limit if you have three files with 1, 9999 and 10000
> changed lines and your terminal is only 200 columns wide.
>
> The current code caps name part to 50/80, but allows the graph to use more
> when you have only shorter names.  Perhaps you can follow the same logic
> in the first part of your [7/8] (which needs to be separated to at least
> in two pieces, as it conflates the "lift 50-column cap from the name width
> and make it proportional to the term_width()" part and "but cap the graph
> part to 40-column" part, that are separate topics)?  Then we can try
> different heuristics to find a better way to cap the length of the graph
> on top?

Sure. I'll be replying to this mail with patches
  [7.1/8] use a maximum of 5/8 for the filename part
  [7.2/8] add a test for output with COLUMNS=40
  [7.3/8] limit graph part to 40 columns

-- Zbyszek