Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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. 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? -- 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