-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
git-gui commit text widget stays fixed in size when expanding the top window horizontally #53
Comments
@dzach Thanks for the patches. The current width of the commit message window matches exactly the "Commit message text width" option in the options menu. This is supposed to give a visual cue to the user that they are reaching their desired commit message width limit and they should break the line. I don't think it is wise to break that flow without providing a replacement. One option that I considered was to introduce line wrapping. The line wrapping in your patches is soft wrapping. It only wraps the line visually. The actual line in memory stays intact. This would mean that the text in the commit message will not be wrapped. I am thinking more about hard line wrapping, something like the ones done by text editors like vim or emacs. I welcome patches if you are interested in that feature. But please don't send them in a zip file. They are very hard to review and provide feedback on in that format. Look at the README to see how you can send patches. |
Thank you for the reply @prati0100
I'm sorry I overlooked the instructions for how to contribute. |
There is a horizontal scrollbar present at the bottom of the text box. It is only activated when a line actually crosses the text box width. It can serve as a visual cue that one of your lines has crossed the line length. And you can always scroll back to the start for other lines.
Right, keeping a soft wrap does make it a bit easier to read the full message with some lines which are too long. But it has some downsides as well. For example, from your screenshots I can see that the difference between a soft-wrapped line and the next line is very subtle and not every user might notice it, or notice it quickly enough.
Usually, the practice is to make sure your subject line never exceeds the width. But I don't think tools should enforce this unconditionally. They should give the users tools to enforce it if they so wish. So when I say hard wrap, I mean that it should include an option to not hard wrap a line when a user doesn't want it. We can look at popular text editors and see how they do this. For example, in vim you can set it to automatically hard wrap but when you press Just so this response is not just a bunch of vague arguments, I'll summarize what I think. I think the current system is fine, although there is certainly room for improvement. Increasing the text box width is not one of them. I am open to a soft wrap option but I think it will be difficult to get right. Quickly differentiating between lines with soft and hard breaks is an important thing and I am not convinced Tk's current implementation does a very good job of it. So if you do want to implement soft wraps either figure out a way to very clearly differentiate between the two or make it an option disabled by default. My most preferred option would be to add hard wraps with the ability to manually make lines larger than the limit if the user wants to do so. |
Ok. I'll try to work out some solutions for both soft and hard wrap, as soon as free time perimits. |
Hi
This refers to the latest Tcl/Tk git-gui.sh code git version 2.17.1, from https://github.com/git/git.
It's not a new thing. It has been present in git-gui since the beginning, I believe.
Problem:
When expanding the top level window of the stock git-gui interface, the 'Commit Message' text widget remains fixed in size. Long message lines may be partially hidden, since the same text widget has its -wrap option set to none, and the rest of the now expanded area to the right of the text widget remains empty, as far as I can see, unless there is some other functionality that uses that empty space, which I have not encountered over the years.
Proposed solution
Attached are two trivial patches and three images of the resulting appearance.
Thanks.
git-gui.zip
The text was updated successfully, but these errors were encountered: