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

["Zbigniew Jędrzejewski-Szmek" <zbyszek@in.waw.pl>]

On 02/21/2012 08:05 AM, Junio C Hamano wrote:
> Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl>  writes:
>
>> On 02/21/2012 12:41 AM, Junio C Hamano wrote:
>>> Zbigniew Jędrzejewski-Szmek<zbyszek@in.waw.pl>   writes:
>>>
>>>> JC:
>>>>> Perhaps the maximum for garph_width should be raised to something like
>>>>> "min(80, stat_width) - name_width"?
>>>> I think that a graph like
>>>> a | 1000 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> b |    1 -
>>>> is not very readable. I like the consistency forced by the 40-column limit.
>>>> But I guess that this is very subjective.
>>>
>>> The above makes it very obvious that there is a huge amount of change made
>>> to 'a' and a bit of deletion to 'b', compared to a mini-graph that is
>>> truncated to half the screen width.
>> Yes. But the same graph with 40 columns tells me exactly the same thing.
>
> That is a bogus argument, isn't it?  You can say the same thing if you
> limited the length of the graph bars to 10-columns if you only compare
> between 1000 and 1. You can even do with just 5-columns.  For that matter,
> without any graph bar at all, it tells us exactly the same thing because
> we have numbers.  Does that mean we do not need any bar?  Of course not.
> We use bars as visual aid.
Yes.

> Imagine what happens to the graph if you had paths with medium amount of
> changes like 980, 800, 40, in addition to 1000 and 1.  By limiting the
> length of the bars more than necessary, you are losing the resolution
> without a good reason, and that is why I find 40-column limit a poor
> design choice.
You're right.

>>> Besides, the above is what you would get without your patch on 80-column
>>> terminal, no?
>>
>> Yes.
>
> I think this "use at most 40-places for the graph bar" was your response
> to somebody's observation that "on 200-column terminal, we will still see
> the commit log messages (and for many projects, also patch text) that are
> designed to be comfortably viewable within the 80-column on the left, and
> overlong graph bar stands out like an ugly sore thumb".
>
> While that "ugliness" observation might be a valid one to make, I do not
> think limiting the length of the graph bar without taking the length of
> the name part into account at all is the right solution to it.
>
> After all, that is exactly the same thinking that led to the bug in the
> current code that you fixed with your series, isn't it?  Our safety code
> truncated the graph bar width too early without taking the width needed to
> show the names into account, and then when the names turn out to be all
> short, we ended up wasting space on the right hand side, because we made
> the bars too short and the decision was made too early in the code.
>
> If the problem you are addressing is to make sure that the diffstat part
> in the series of lines that are structured like this:
>
>     log message part ~80 column
>     diff stat part that can extend very very very very very very very long
>     patch text part  ~80 column
>
> does not become overly long, wouldn't it be a more natural solution to
> make sure that when the total (i.e. name and graph) length can fit to
> align with the message and patch (i.e. traditional ~80 col regardless of
> the terminal width), not to give it too much width?  If the names are
> short, like "a" and "b", that may result in graph bar part to use ~70
> columns or so, and if the names are long, like in a Java project, you may
> allocate 50 columns to the name and leave only 50 columns or so for the
> graph part.
>
> A simple heuristic might be to see if name part (without truncation) and
> the graph part (without scaling) fits under 100-columns if the terminal is
> wider than that, and if so limit the whole thing to 100-columns before
> deciding the allocation of the total into two parts.  If the name part
> alone is very wide, showing the name and the graph using the whole
> terminal width would give you a better result than using the bars that are
> artificially capped to a short limit, I would imagine.
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
   71 = (available space if stat_width==80 and the filename is "a" and
         the change count is in double digits).
Then if the filenames are longer, and the change counts are big enough,
the graph part starts gently extending above 80 columns.

What do you think about this approach?

Zbyszek