git-gui: allow larger width for the commit message buffer

[alshopov]

Small adjustments to allow the buffer for the commit message to reflow with the window. Changes concern the .vpane.lower.commarea.buffer branch of the widget tree.
Update the label for the config value in the settings window

[alshopov]

This is a continuation of #33
I think I followed you advice. Both commit itself and commit message should be according to what you said in #33.
This change does not fix the fact that change setting need restart of the app to be applied.

[j6t]

While testing, I found that we do not need the special case. Just make the width really large, like 2000. This would then also be backward compatible. Therefore, it should be sufficient to increase the allowed range to a lot more than 99.

Also, it would be "allow the commit message field to resize". "Reflow" is something different. And please make sure not to sneak in unrelated changes, like the new empty line.

[alshopov]

@j6t This pull request should be the minimum change according to what we discussed.

Please also have a look at the alternative pull request #35 , it contains this commit plus two more. If you merge any of these two requests - I will close the other, this is just to save some more edits from your side.

[j6t]

Please don't spam pull request about topics that are basically the same.

Why not go from 99 to 9999 in the first try?

Let me suggest this commit message (note, not "buffer", but "field"):

git-gui: allow larger width for the commit message field

Users may like to make the main window very wide. In this case, a rather small size of the commit message field leaves a wide unused space at the bottom-right. Allow to set to field width to much larger values than 99 characters. In fact, users can set it to extreme values to fill the entire space regardless of window width; the widget geometry will be negotiated to be limited to the available space despite the large requested width.

[alshopov]

@j6t Pull request updated as requested.
Just to point it out - I have changed the message in the options window to hint about the behavior.

[j6t]

I'm actually not happy with the new label. For one, "1000" is an arbitrary value and smaller values work, too. For another, "fit to window" is dictated by good user interface behavior (no text remains invisible outside the window and is inaccessible), but is actually not a design goal in itself.

So, if you are setting the value very high, you are actually exploiting an implementation detail.

[alshopov]

I think you are nitpicking here. However the label is not a hill I will die on.
I will revert it to the previous state. While discoverability of the feature is lost, the interface translations will stay current. You would still be free to later change it to anything you see fit.

As long as I know the chicanery to get the behavior I want - that will do it for me.

At the beginning I though I should add such information via a tooltip but within Tcl/Tk that needs an additional require which may be an overhead for git-gui which tries to minimize dependencies.

you are actually exploiting an implementation detail

That is true but I think we settled on your proposal to not use a special case so I guess this should be OK for now.

Would the change be OK now for merge? I feel I am wasting way too much time for effectively a two character change for widget width.

[alshopov]

@j6t Hannes,
The diff now contains only the change you accepted and the commit message is in sync with your proposed one.

[j6t]

Thanks, this looks good.

I feel I am wasting way too much time for effectively a two character change for widget width.

"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."