{"thread":{"id":"51802","subject":"[PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","startedAt":"2019-09-04T20:10:28Z","lastAt":"2019-09-12T19:26:35Z","messageCount":21,"participants":["Bert Wesarg","Eric Sunshine","Pratyush Yadav","Johannes Sixt","Birger Skogeng Pedersen","Philip Oakley","David Aguilar"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"381819","messageId":"7da71d89f9fa987eca2e25974e4cec382c146e44.1567627609.git.bert.wesarg@googlemail.com","threadId":"51802","inReplyTo":null,"subject":"[PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-04T20:10:22Z","receivedAt":"2019-09-04T20:10:28Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"The commit message widget does not wrap the next and has a configurable\nfixed width to avoid creating too wide commit messages. Though this was\nonly enforced in the GUI. Now we also check the commit message at commit\ntime for long lines and ask the author for confirmation if it exceeds the\nconfigured line length.\n\nNeeds Tcl 8.6 because of `lmap`.\n\nSigned-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n---\n git-gui.sh     |  4 ++--\n lib/commit.tcl | 10 ++++++++++\n 2 files changed, 12 insertions(+), 2 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex 5bc21b8..a491085 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -31,8 +31,8 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA}]\n ##\n ## Tcl/Tk sanity check\n \n-if {[catch {package require Tcl 8.4} err]\n- || [catch {package require Tk  8.4} err]\n+if {[catch {package require Tcl 8.6} err]\n+ || [catch {package require Tk  8.6} err]\n } {\n \tcatch {wm withdraw .}\n \ttk_messageBox \\\ndiff --git a/lib/commit.tcl b/lib/commit.tcl\nindex 83620b7..fa9760b 100644\n--- a/lib/commit.tcl\n+++ b/lib/commit.tcl\n@@ -215,6 +215,16 @@ A good commit message has the following format:\n \t\tunlock_index\n \t\treturn\n \t}\n+\tif {[tcl::mathfunc::max {*}[lmap x [split $msg \"\\n\"] {string length $x}]] >= $repo_config(gui.commitmsgwidth) \\\n+\t    && [ask_popup \"Commit message contains lines longer than $repo_config(gui.commitmsgwidth) characters.\n+\n+You may change this limit in the options.\n+\n+Continue to commit?\n+\"] ne yes} {\n+\t\tunlock_index\n+\t\treturn\n+\t}\n \n \t# -- Build the message file.\n \t#\n-- \n2.21.0.789.ga095d9d866\n\n"},{"id":"381820","messageId":"62ef03a2938ac0d2158b1c3201c7f10e52e30ecb.1567627609.git.bert.wesarg@googlemail.com","threadId":"51802","inReplyTo":"7da71d89f9fa987eca2e25974e4cec382c146e44.1567627609.git.bert.wesarg@googlemail.com","subject":"[PATCH 2/2] git-gui: add horizontal scrollbar to commit buffer","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-04T20:10:23Z","receivedAt":"2019-09-04T20:10:28Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"While the commit message widget has a configurable fixed width, it\nnevertheless allows to write commit messages which exceed this limit.\nThough it does not show this content because there is not scrollbar for\nthis widget. No it is.\n\nThere seems to be a bug in at least up to Tcl/Tk 8.6.8, which does not\nupdate the horizontal scrollbar if one removes the whole content at once.\n\nSuggested-by: Birger Skogeng Pedersen <birger.sp@gmail.com>\nSigned-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n---\n git-gui.sh | 10 ++++++++--\n 1 file changed, 8 insertions(+), 2 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex a491085..fa9c0d2 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -3363,14 +3363,20 @@ ttext $ui_comm -background white -foreground black \\\n \t-relief sunken \\\n \t-width $repo_config(gui.commitmsgwidth) -height 9 -wrap none \\\n \t-font font_diff \\\n+\t-xscrollcommand {.vpane.lower.commarea.buffer.frame.sbx set} \\\n \t-yscrollcommand {.vpane.lower.commarea.buffer.frame.sby set}\n+${NS}::scrollbar .vpane.lower.commarea.buffer.frame.sbx \\\n+\t-orient horizontal \\\n+\t-command [list $ui_comm xview]\n ${NS}::scrollbar .vpane.lower.commarea.buffer.frame.sby \\\n+\t-orient vertical \\\n \t-command [list $ui_comm yview]\n \n+pack .vpane.lower.commarea.buffer.frame.sbx -side bottom -fill x\n pack .vpane.lower.commarea.buffer.frame.sby -side right -fill y\n-pack $ui_comm -side left -fill y\n+pack $ui_comm -side left -fill both -expand 1\n pack .vpane.lower.commarea.buffer.header -side top -fill x\n-pack .vpane.lower.commarea.buffer.frame -side left -fill y\n+pack .vpane.lower.commarea.buffer.frame -side bottom -fill both -expand 1\n pack .vpane.lower.commarea.buffer -side left -fill y\n \n # -- Commit Message Buffer Context Menu\n-- \n2.21.0.789.ga095d9d866\n\n"},{"id":"381824","messageId":"CAPig+cSL0fpc5cVgO1soAksD2b5xadkDLG+JxiDCi5s95VRU_A@mail.gmail.com","threadId":"51802","inReplyTo":"7da71d89f9fa987eca2e25974e4cec382c146e44.1567627609.git.bert.wesarg@googlemail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2019-09-04T20:29:52Z","receivedAt":"2019-09-04T20:30:06Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Sep 4, 2019 at 4:10 PM Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> The commit message widget does not wrap the next and has a configurable\n\ns/next/text/\n\n> fixed width to avoid creating too wide commit messages. Though this was\n> only enforced in the GUI. Now we also check the commit message at commit\n> time for long lines and ask the author for confirmation if it exceeds the\n> configured line length.\n\nHmm, more confirmation dialogs tend to mean more annoyance for users,\nespecially considering that the line length limit is a\nproject-specific _policy_ (so this has the potential to annoy a lot of\npeople), and also because there often are legitimate reasons for\nexceeding the limit (such as pasting in URLs).\n\nAs an alternative to a confirmation dialog, how about instead adding a\n_warning_ message (perhaps with red text) on the window itself\nalongside to the commit message field (below or above it or\nsomething)? Is that something that could be triggered by a text widget\ncallback?\n\n> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n> ---\n> diff --git a/lib/commit.tcl b/lib/commit.tcl\n> @@ -215,6 +215,16 @@ A good commit message has the following format:\n> +       if {[tcl::mathfunc::max {*}[lmap x [split $msg \"\\n\"] {string length $x}]] >= $repo_config(gui.commitmsgwidth) \\\n\nDoes this take TABs into account?\n"},{"id":"381826","messageId":"CAPig+cTZiOBwaM-BE-19CzJuZ4NwCZTaDc22WuY+bv8BLP=rrQ@mail.gmail.com","threadId":"51802","inReplyTo":"62ef03a2938ac0d2158b1c3201c7f10e52e30ecb.1567627609.git.bert.wesarg@googlemail.com","subject":"Re: [PATCH 2/2] git-gui: add horizontal scrollbar to commit buffer","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2019-09-04T20:31:18Z","receivedAt":"2019-09-04T20:31:32Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Sep 4, 2019 at 4:10 PM Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> While the commit message widget has a configurable fixed width, it\n> nevertheless allows to write commit messages which exceed this limit.\n> Though it does not show this content because there is not scrollbar for\n> this widget. No it is.\n\n\"No it is\" what?\n\n> Suggested-by: Birger Skogeng Pedersen <birger.sp@gmail.com>\n> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n"},{"id":"381828","messageId":"CAKPyHN3=hh7DCoyEKB9DOf=t=v=Y1bX1xVx9r6Lxy=WQb9JC-A@mail.gmail.com","threadId":"51802","inReplyTo":"CAPig+cSL0fpc5cVgO1soAksD2b5xadkDLG+JxiDCi5s95VRU_A@mail.gmail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-04T20:43:45Z","receivedAt":"2019-09-04T20:43:58Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Wed, Sep 4, 2019 at 10:30 PM Eric Sunshine <sunshine@sunshineco.com> wrote:\n>\n> On Wed, Sep 4, 2019 at 4:10 PM Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> > The commit message widget does not wrap the next and has a configurable\n>\n> s/next/text/\n\nfixed\n\n>\n> > fixed width to avoid creating too wide commit messages. Though this was\n> > only enforced in the GUI. Now we also check the commit message at commit\n> > time for long lines and ask the author for confirmation if it exceeds the\n> > configured line length.\n>\n> Hmm, more confirmation dialogs tend to mean more annoyance for users,\n> especially considering that the line length limit is a\n> project-specific _policy_ (so this has the potential to annoy a lot of\n> people), and also because there often are legitimate reasons for\n> exceeding the limit (such as pasting in URLs).\n\nthese people did not saw the entered text anyway. they would have\nneeded to change the option (default to 75 characters) to see what\nthey have typed. which could have been garbage to begin with.\n\n>\n> As an alternative to a confirmation dialog, how about instead adding a\n> _warning_ message (perhaps with red text) on the window itself\n> alongside to the commit message field (below or above it or\n> something)? Is that something that could be triggered by a text widget\n> callback?\n\nHow about a horizontal scrollbar? This indicates pretty conveniently\nand in a standard visual way, that there is more text to the side ;-)\n\n\n>\n> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n> > ---\n> > diff --git a/lib/commit.tcl b/lib/commit.tcl\n> > @@ -215,6 +215,16 @@ A good commit message has the following format:\n> > +       if {[tcl::mathfunc::max {*}[lmap x [split $msg \"\\n\"] {string length $x}]] >= $repo_config(gui.commitmsgwidth) \\\n>\n> Does this take TABs into account?\n\nprobably not. Does git expands tabs if it wrap lines (git shortlog's -w option)?\n"},{"id":"381829","messageId":"CAKPyHN0B++3w7GgTPCE6P=rWBivknfqA0YZnJdz3htbOCa0g+w@mail.gmail.com","threadId":"51802","inReplyTo":"CAPig+cTZiOBwaM-BE-19CzJuZ4NwCZTaDc22WuY+bv8BLP=rrQ@mail.gmail.com","subject":"Re: [PATCH 2/2] git-gui: add horizontal scrollbar to commit buffer","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-04T20:46:14Z","receivedAt":"2019-09-04T20:46:28Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Wed, Sep 4, 2019 at 10:31 PM Eric Sunshine <sunshine@sunshineco.com> wrote:\n>\n> On Wed, Sep 4, 2019 at 4:10 PM Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> > While the commit message widget has a configurable fixed width, it\n> > nevertheless allows to write commit messages which exceed this limit.\n> > Though it does not show this content because there is not scrollbar for\n> > this widget. No it is.\n>\n> \"No it is\" what?\n\n…there is no scrollbar for this widget. Now there is.\n\nfixed\n\n>\n> > Suggested-by: Birger Skogeng Pedersen <birger.sp@gmail.com>\n> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n"},{"id":"381848","messageId":"20190904224821.mgh4srhc22grkraz@yadavpratyush.com","threadId":"51802","inReplyTo":"CAKPyHN3=hh7DCoyEKB9DOf=t=v=Y1bX1xVx9r6Lxy=WQb9JC-A@mail.gmail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-09-04T22:48:21Z","receivedAt":"2019-09-04T22:48:27Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 04/09/19 10:43PM, Bert Wesarg wrote:\n[snip]\n> > > fixed width to avoid creating too wide commit messages. Though \n> > > this was\n> > > only enforced in the GUI. Now we also check the commit message at commit\n> > > time for long lines and ask the author for confirmation if it exceeds the\n> > > configured line length.\n> >\n> > Hmm, more confirmation dialogs tend to mean more annoyance for users,\n> > especially considering that the line length limit is a\n> > project-specific _policy_ (so this has the potential to annoy a lot of\n> > people), and also because there often are legitimate reasons for\n> > exceeding the limit (such as pasting in URLs).\n> \n> these people did not saw the entered text anyway. they would have\n> needed to change the option (default to 75 characters) to see what\n> they have typed. which could have been garbage to begin with.\n\nNot true in my experience. Sure, no scrollbar appears, but the view of \nthe textbox still scrolls when I type in a long line. I can go back to \nseeing the start of the line by moving with the arrow keys.\n\nThe point being, you _can_ see what you typed. Do you not get this \nbehaviour in Windows (or whatever platform you use)? Maybe that is a \nTcl/Tk problem?\n\n> > As an alternative to a confirmation dialog, how about instead adding \n> > a\n> > _warning_ message (perhaps with red text) on the window itself\n> > alongside to the commit message field (below or above it or\n> > something)? Is that something that could be triggered by a text widget\n> > callback?\n\nI'll chime in with what I think would be a great solution: auto word \nwrapping. This way, the users can set the text width, and not have to \nworry about manually formatting it. Long \"words\" like URLs would still \nget to be on one line, and we avoid showing annoying dialogs.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"381856","messageId":"ef44ce71-2ed7-0f17-faf2-06b3c7d193b9@kdbg.org","threadId":"51802","inReplyTo":"CAKPyHN3=hh7DCoyEKB9DOf=t=v=Y1bX1xVx9r6Lxy=WQb9JC-A@mail.gmail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-09-05T06:21:59Z","receivedAt":"2019-09-05T06:22:04Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 04.09.19 um 22:43 schrieb Bert Wesarg:\n> these people did not saw the entered text anyway. they would have\n> needed to change the option (default to 75 characters) to see what\n> they have typed. which could have been garbage to begin with.\n\nHuh? When I type overly long line, all text scrolls out of view on the\nleft side. So I definitely _can_ see the long text.\n\n> How about a horizontal scrollbar? This indicates pretty conveniently\n> and in a standard visual way, that there is more text to the side ;-)\n\nThe scrollbar is an option, of course, but I dislike somewhat that it\ntakes away screen space if it is permanently visible.\n\n-- Hannes\n"},{"id":"381858","messageId":"CAGr--=J1YmMbud4tcZjAZ06m0CmRbAqQTzs+FTgeJkJp4d2FzQ@mail.gmail.com","threadId":"51802","inReplyTo":"20190904224821.mgh4srhc22grkraz@yadavpratyush.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Birger Skogeng Pedersen","fromEmail":"birger.sp@gmail.com","sentAt":"2019-09-05T06:48:35Z","receivedAt":"2019-09-05T06:51:02Z","isPatch":true,"sender":{"key":"birger.sp@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5260237?v=4"},"body":"On Thu, Sep 5, 2019 at 12:48 AM Pratyush Yadav <me@yadavpratyush.com> wrote:\n> I'll chime in with what I think would be a great solution: auto word\n> wrapping. This way, the users can set the text width, and not have to\n> worry about manually formatting it. Long \"words\" like URLs would still\n> get to be on one line, and we avoid showing annoying dialogs.\n\n+1. IMO git-gui really needs automatic word wrapping for the commit messages.\n\nBirger\n"},{"id":"381885","messageId":"CAKPyHN3w-21k0+Sm78N69MZ8HqgnS+TRFkvi4oE5qVF6R0JTdw@mail.gmail.com","threadId":"51802","inReplyTo":"ef44ce71-2ed7-0f17-faf2-06b3c7d193b9@kdbg.org","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-05T17:43:02Z","receivedAt":"2019-09-05T17:43:16Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Thu, Sep 5, 2019 at 8:22 AM Johannes Sixt <j6t@kdbg.org> wrote:\n>\n> Am 04.09.19 um 22:43 schrieb Bert Wesarg:\n> > these people did not saw the entered text anyway. they would have\n> > needed to change the option (default to 75 characters) to see what\n> > they have typed. which could have been garbage to begin with.\n>\n> Huh? When I type overly long line, all text scrolls out of view on the\n> left side. So I definitely _can_ see the long text.\n\nwrong memory bank, sorry. Though imagine you paste in some multi line\ntext, and one line is too long but the next not. In this case you wont\nsee the too long part anymore.\n\n>\n> > How about a horizontal scrollbar? This indicates pretty conveniently\n> > and in a standard visual way, that there is more text to the side ;-)\n>\n> The scrollbar is an option, of course, but I dislike somewhat that it\n> takes away screen space if it is permanently visible.\n\nI already argued against an auto-hide scrollbar, which was also acked by ohers:\n\nOn 02.09.19 19:58, Bert Wesarg wrote:\n> On Mon, Sep 2, 2019 at 7:35 PM Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> True, and that reasoning would justify hiding scrollbar when not\n>> necessary to gain vertical space.  Can we arrange the scrollbar to\n>> appear only when needed?\n>\n> up to now, git-gui does not hide any scrollbars, if they are not\n> needed. IMHO, I would keep it that way, as I don't like the flicker\n> when it appears and disappears. Imagine you are typing in the bottom\n> line and than you typed too much. The scrollbar appears, your input\n> line jumps one up line (or is hidden behind the scrollbar), than you\n> remove the too long line, the scrollbar disappears again and your\n> input line jumps down again.\n\n>\n> -- Hannes\n"},{"id":"381887","messageId":"CAKPyHN1VeK4bR3Dn5yjrs2UwT5XGKOPU_FHaMBsP+riM-bjeWA@mail.gmail.com","threadId":"51802","inReplyTo":"CAGr--=J1YmMbud4tcZjAZ06m0CmRbAqQTzs+FTgeJkJp4d2FzQ@mail.gmail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-05T17:46:29Z","receivedAt":"2019-09-05T17:46:41Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Thu, Sep 5, 2019 at 8:50 AM Birger Skogeng Pedersen\n<birger.sp@gmail.com> wrote:\n>\n> On Thu, Sep 5, 2019 at 12:48 AM Pratyush Yadav <me@yadavpratyush.com> wrote:\n> > I'll chime in with what I think would be a great solution: auto word\n> > wrapping. This way, the users can set the text width, and not have to\n> > worry about manually formatting it. Long \"words\" like URLs would still\n> > get to be on one line, and we avoid showing annoying dialogs.\n>\n> +1. IMO git-gui really needs automatic word wrapping for the commit messages.\n\nPlease exclude the first line, i.e., the subject. This should not be\nwrapped at all.\n\nI also imagine, that we should make it configurable, I'm unsure if I\nwould use this feature for my self.\n\nBert\n\n>\n> Birger\n"},{"id":"381956","messageId":"CAGr--=JpsgESv8W90-iT11VCAD3xQYipN3+Tt7cNyeZrsvhP_Q@mail.gmail.com","threadId":"51802","inReplyTo":"CAKPyHN1VeK4bR3Dn5yjrs2UwT5XGKOPU_FHaMBsP+riM-bjeWA@mail.gmail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Birger Skogeng Pedersen","fromEmail":"birger.sp@gmail.com","sentAt":"2019-09-06T14:08:00Z","receivedAt":"2019-09-06T14:08:15Z","isPatch":true,"sender":{"key":"birger.sp@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5260237?v=4"},"body":"Hi Bert,\n\n\nWe should probably distinguish between what is wrapped in git-gui\n(i.e. purely visual), and what is actually wrapped in the commit\nmessage.\nI believe the former is referred to as \"soft wrap\", while the latter\nis \"hard wrap\".\n\n\nOn Thu, Sep 5, 2019 at 7:46 PM Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> Please exclude the first line, i.e., the subject. This should not be\n> wrapped at all.\n\nI think all lines should be soft wrapped. Scrolling sideways is just\nnot something I'd want to do in the gui.\n\nHow about we soft wrap all lines (in gui). But when the commit is\ncreated, the actual hard wrap (newline characters) happens only on\nlines other than the first one?\n\nBut then again, the user might get frustrated when the resulting\ncommit message looks different than what it appeared in git-gui.\n\nHonestly I'd prefer just wrap the first line as well. If the user gets\nfrustrated that the first line gets wrapped there are two options:\n- Refrain from writing such a long line\n- Disable word wrapping (it should be configurable, like you said)\n\nThoughts?\n\n\n\nBirger\n"},{"id":"381983","messageId":"ed572a47-b3d1-028f-0576-aac6c922671e@iee.email","threadId":"51802","inReplyTo":"CAGr--=JpsgESv8W90-iT11VCAD3xQYipN3+Tt7cNyeZrsvhP_Q@mail.gmail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-09-06T20:07:15Z","receivedAt":"2019-09-06T20:07:21Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Birger,\n\nOn 06/09/2019 15:08, Birger Skogeng Pedersen wrote:\n> Hi Bert,\n>\n>\n> We should probably distinguish between what is wrapped in git-gui\n> (i.e. purely visual), and what is actually wrapped in the commit\n> message.\n> I believe the former is referred to as \"soft wrap\", while the latter\n> is \"hard wrap\".\n>\n>\n> On Thu, Sep 5, 2019 at 7:46 PM Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n>> Please exclude the first line, i.e., the subject. This should not be\n>> wrapped at all.\n> I think all lines should be soft wrapped. Scrolling sideways is just\n> not something I'd want to do in the gui.\n>\n> How about we soft wrap all lines (in gui). But when the commit is\n> created, the actual hard wrap (newline characters) happens only on\n> lines other than the first one?\n\nNot sure if I parsed this correctly, but I'd want a WYSIWYG approach \nthat if we wrap on the display it will be wrapped (newline char) in the \ncommit. It sounded as if you were proposing a soft wrap visually, but \nnot doing the same for the commit.\n\nPersonally, I've had both feelings with the gui. I like that the 'hard' \nvisual char limit is there that encourages me to wrap my messages.\nBut at the same time if I'm typing on a flow then it's annoying that \nthere wasn't any auto wrap.\n\nThe other problem is if one is amending a commit and I need to add a few \nword mid paragraph, the manual re-flowing and manual wrapping can be \nannoying.\n\nI suspect there is a moderately happy medium between the two, perhaps \nwith an autowrap key (per paragraph) being available.\n\nI also had it in my head that some parts of Git do allow more than a \nsingle line headers, or at least can cope with a run-on second line \nbefore the blank line that flags the start of the message proper. (I may \nbe wrong...)\n> But then again, the user might get frustrated when the resulting\n> commit message looks different than what it appeared in git-gui.\n>\n> Honestly I'd prefer just wrap the first line as well. If the user gets\n> frustrated that the first line gets wrapped there are two options:\n> - Refrain from writing such a long line\n> - Disable word wrapping (it should be configurable, like you said)\nConfigurable wrapping point - yes, would be nice (a feeling of control, \nthat I'd probably never change ;-).\n>\n> Thoughts?\n>\n>\n>\n> Birger\nPhilip\n"},{"id":"382122","messageId":"20190910080408.GA32239@gmail.com","threadId":"51802","inReplyTo":"ed572a47-b3d1-028f-0576-aac6c922671e@iee.email","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2019-09-10T08:04:08Z","receivedAt":"2019-09-10T08:04:14Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Fri, Sep 06, 2019 at 09:07:15PM +0100, Philip Oakley wrote:\n> Hi Birger,\n> \n> On 06/09/2019 15:08, Birger Skogeng Pedersen wrote:\n> > Hi Bert,\n> > \n> > \n> > We should probably distinguish between what is wrapped in git-gui\n> > (i.e. purely visual), and what is actually wrapped in the commit\n> > message.\n> > I believe the former is referred to as \"soft wrap\", while the latter\n> > is \"hard wrap\".\n> > \n> > \n> > On Thu, Sep 5, 2019 at 7:46 PM Bert Wesarg <bert.wesarg@googlemail.com> wrote:\n> > > Please exclude the first line, i.e., the subject. This should not be\n> > > wrapped at all.\n> > I think all lines should be soft wrapped. Scrolling sideways is just\n> > not something I'd want to do in the gui.\n> > \n> > How about we soft wrap all lines (in gui). But when the commit is\n> > created, the actual hard wrap (newline characters) happens only on\n> > lines other than the first one?\n> \n> Not sure if I parsed this correctly, but I'd want a WYSIWYG approach that if\n> we wrap on the display it will be wrapped (newline char) in the commit. It\n> sounded as if you were proposing a soft wrap visually, but not doing the\n> same for the commit.\n> \n> Personally, I've had both feelings with the gui. I like that the 'hard'\n> visual char limit is there that encourages me to wrap my messages.\n> But at the same time if I'm typing on a flow then it's annoying that there\n> wasn't any auto wrap.\n> \n> The other problem is if one is amending a commit and I need to add a few\n> word mid paragraph, the manual re-flowing and manual wrapping can be\n> annoying.\n> \n> I suspect there is a moderately happy medium between the two, perhaps with\n> an autowrap key (per paragraph) being available.\n> \n> I also had it in my head that some parts of Git do allow more than a single\n> line headers, or at least can cope with a run-on second line before the\n> blank line that flags the start of the message proper. (I may be wrong...)\n\n\nCorrect, you're thinking about the subject line -- it has that\nmulti-line behavior.\n\nIn git-cola we use a separate LineEdit for the \"Commit summary\" line,\nwhich has improved the commit messages users write and is good because\nthe user doesn't need to worry about the \"blank line between subject and\nbody\" Git commit message convention.\n\nWhen the user presses \"enter\" in the subject line it jumps to the\n\"Extended description\" TextEdit, so it still \"feels\" like a single\nwidget.  Likewise, up-arrow from the first line of the Extended\ndescription also jumps to the summary LineEdit.  We also have a \"Ctrl-L\"\nglobal hotkey to jump back to the subject line (same hotkey as Web\nbrowsers for the \"hot\" action of focusing the URL).\n\nUsing two widgets is a bigger rework for git-gui, but should be\nconsidered for future enhancement.\n\nWe also deal with the \"Amend a commit\" issue through the word-wrap\napproach.  It's actually a paragraph reflow (not a line-by-line wrap) so\nadding words is fine and easy and does the natural expected thing --\nwhen amending it'll still feel like a long flow line and when committed\nit'll wrap with newlines at the configured column.\n\n\n> > But then again, the user might get frustrated when the resulting\n> > commit message looks different than what it appeared in git-gui.\n> > \n> > Honestly I'd prefer just wrap the first line as well. If the user gets\n> > frustrated that the first line gets wrapped there are two options:\n> > - Refrain from writing such a long line\n> > - Disable word wrapping (it should be configurable, like you said)\n> Configurable wrapping point - yes, would be nice (a feeling of control, that\n> I'd probably never change ;-).\n> > \n> > Thoughts?\n\n\nThose are the same controls git-cola has.\n- Commit message word-wrap can be turned on/off.  Defaults to on.\n- The line length is configurable.  Defaults to 72.\n\nRegarding, \"the user might get frusted when the resulting commit message\nlooks different\" -- I don't think that's really a concern in practice\nbut that might be we have a dedicated LineEdit for the subject line.\n\nFor git-gui, it seems fine since Git already has conventions about how\nthe subject line gets wrapped, so tools will still see the wrapped\nsubject line as a logical \"single line\".\n\nThe \"Extended description\" commit message editor is WYSWIYG, but if the\nwidget is smaller than the configured value then we still wrap the\ncommitted message using the configured value, which is what the user\nwould likely expect even though the visual wrapping is smaller.\n\nWe also special-case trailers like \"Signed-off-by:\" and other common\ntrailers since user names can get long, and users sometimes use things\nlike \"See-also:\" and paste a long URL that we don't want to wrap.\n\nLastly, we have a convenient session-only checkbox to temporarily disable\nwrapping for a commit that does not persist across restarts.  The idea\nis that sometimes you might use the GUI for a one-off commit where you\nwant to disable the wrapping for whatever reason, but don't want to\nchange your configuration.\n-- \nDavid\n"},{"id":"382138","messageId":"01e3c41d-af69-f9b3-31e6-12192e566f92@kdbg.org","threadId":"51802","inReplyTo":"7da71d89f9fa987eca2e25974e4cec382c146e44.1567627609.git.bert.wesarg@googlemail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-09-10T16:50:41Z","receivedAt":"2019-09-10T16:50:45Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 04.09.19 um 22:10 schrieb Bert Wesarg:\n> The commit message widget does not wrap the next and has a configurable\n> fixed width to avoid creating too wide commit messages. Though this was\n> only enforced in the GUI. Now we also check the commit message at commit\n> time for long lines and ask the author for confirmation if it exceeds the\n> configured line length.\n> \n> Needs Tcl 8.6 because of `lmap`.\n> \n> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n> ---\n>  git-gui.sh     |  4 ++--\n>  lib/commit.tcl | 10 ++++++++++\n>  2 files changed, 12 insertions(+), 2 deletions(-)\n> \n> diff --git a/git-gui.sh b/git-gui.sh\n> index 5bc21b8..a491085 100755\n> --- a/git-gui.sh\n> +++ b/git-gui.sh\n> @@ -31,8 +31,8 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA}]\n>  ##\n>  ## Tcl/Tk sanity check\n>  \n> -if {[catch {package require Tcl 8.4} err]\n> - || [catch {package require Tk  8.4} err]\n> +if {[catch {package require Tcl 8.6} err]\n> + || [catch {package require Tk  8.6} err]\n>  } {\n>  \tcatch {wm withdraw .}\n>  \ttk_messageBox \\\n> diff --git a/lib/commit.tcl b/lib/commit.tcl\n> index 83620b7..fa9760b 100644\n> --- a/lib/commit.tcl\n> +++ b/lib/commit.tcl\n> @@ -215,6 +215,16 @@ A good commit message has the following format:\n>  \t\tunlock_index\n>  \t\treturn\n>  \t}\n> +\tif {[tcl::mathfunc::max {*}[lmap x [split $msg \"\\n\"] {string length $x}]] >= $repo_config(gui.commitmsgwidth) \\\n\nThis has an off-by-one error: When I fill the edit box to the limit, but\nnot beyond it, I get the warning popup. I guess this should be '>', not\n'>='.\n\n> +\t    && [ask_popup \"Commit message contains lines longer than $repo_config(gui.commitmsgwidth) characters.\n> +\n> +You may change this limit in the options.\n> +\n> +Continue to commit?\n> +\"] ne yes} {\n> +\t\tunlock_index\n> +\t\treturn\n> +\t}\n>  \n>  \t# -- Build the message file.\n>  \t#\n> \n\n-- Hannes\n"},{"id":"382147","messageId":"20190910194202.weior75tzpd7iapg@yadavpratyush.com","threadId":"51802","inReplyTo":"20190910080408.GA32239@gmail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-09-10T19:42:02Z","receivedAt":"2019-09-10T19:42:08Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 10/09/19 01:04AM, David Aguilar wrote:\n> On Fri, Sep 06, 2019 at 09:07:15PM +0100, Philip Oakley wrote:\n> > \n> > Not sure if I parsed this correctly, but I'd want a WYSIWYG approach that if\n> > we wrap on the display it will be wrapped (newline char) in the commit. It\n> > sounded as if you were proposing a soft wrap visually, but not doing the\n> > same for the commit.\n> > \n> > Personally, I've had both feelings with the gui. I like that the 'hard'\n> > visual char limit is there that encourages me to wrap my messages.\n> > But at the same time if I'm typing on a flow then it's annoying that there\n> > wasn't any auto wrap.\n> > \n> > The other problem is if one is amending a commit and I need to add a few\n> > word mid paragraph, the manual re-flowing and manual wrapping can be\n> > annoying.\n> > \n> > I suspect there is a moderately happy medium between the two, perhaps with\n> > an autowrap key (per paragraph) being available.\n> > \n> > I also had it in my head that some parts of Git do allow more than a single\n> > line headers, or at least can cope with a run-on second line before the\n> > blank line that flags the start of the message proper. (I may be wrong...)\n> \n> \n> Correct, you're thinking about the subject line -- it has that\n> multi-line behavior.\n> \n> In git-cola we use a separate LineEdit for the \"Commit summary\" line,\n> which has improved the commit messages users write and is good because\n> the user doesn't need to worry about the \"blank line between subject and\n> body\" Git commit message convention.\n> \n> When the user presses \"enter\" in the subject line it jumps to the\n> \"Extended description\" TextEdit, so it still \"feels\" like a single\n> widget.  Likewise, up-arrow from the first line of the Extended\n> description also jumps to the summary LineEdit.  We also have a \"Ctrl-L\"\n> global hotkey to jump back to the subject line (same hotkey as Web\n> browsers for the \"hot\" action of focusing the URL).\n\nI'm not sure how good this idea is. I feel like we should keep it simple \nand trust the user to know what they are doing. Two textboxes seems like \na lot of clutter for not that much benefit. I've not seen many people \ncomplain about hitting the extra \"enter\". Plus, we get to keep our \nmessage buffer the same as when a user would use a plain text editor.\n\nOne idea I have for dealing with users wanting a longer subject line is \nto do something like git-format-patch's subject line is formatted (this \ncould be an mbox thing, and not send-email specific). When the subject \nis too long, the subject is broken in multiple lines, but the first \ncharacter on the next line is a space, so it signifies a continued \nsubject.\n\nSomething like:\nSubject: foo bar baz\n abcd  \n\nWhich gets converted to \"foo bar baz abcd\" in the commit message.\n\n> \n> Using two widgets is a bigger rework for git-gui, but should be\n> considered for future enhancement.\n> \n> We also deal with the \"Amend a commit\" issue through the word-wrap\n> approach.  It's actually a paragraph reflow (not a line-by-line wrap) so\n> adding words is fine and easy and does the natural expected thing --\n> when amending it'll still feel like a long flow line and when committed\n> it'll wrap with newlines at the configured column.\n\nYes, a paragraph reflow is what I had in mind. Without it editing \nalready written lines is a pain.\n\n> > > But then again, the user might get frustrated when the resulting\n> > > commit message looks different than what it appeared in git-gui.\n> > > \n> > > Honestly I'd prefer just wrap the first line as well. If the user gets\n> > > frustrated that the first line gets wrapped there are two options:\n> > > - Refrain from writing such a long line\n> > > - Disable word wrapping (it should be configurable, like you said)\n> > Configurable wrapping point - yes, would be nice (a feeling of control, that\n> > I'd probably never change ;-).\n> > > \n> > > Thoughts?\n> \n> \n> Those are the same controls git-cola has.\n> - Commit message word-wrap can be turned on/off.  Defaults to on.\n> - The line length is configurable.  Defaults to 72.\n> \n> Regarding, \"the user might get frusted when the resulting commit message\n> looks different\" -- I don't think that's really a concern in practice\n> but that might be we have a dedicated LineEdit for the subject line.\n\nThe aim is to have the commit message be exactly what the user sees. But \nI'm not sure how feasible that is considering the tools/APIs we have to \nwork with.\n \n> For git-gui, it seems fine since Git already has conventions about how\n> the subject line gets wrapped, so tools will still see the wrapped\n> subject line as a logical \"single line\".\n> \n> The \"Extended description\" commit message editor is WYSWIYG, but if the\n> widget is smaller than the configured value then we still wrap the\n> committed message using the configured value, which is what the user\n> would likely expect even though the visual wrapping is smaller.\n> \n> We also special-case trailers like \"Signed-off-by:\" and other common\n> trailers since user names can get long, and users sometimes use things\n> like \"See-also:\" and paste a long URL that we don't want to wrap.\n\nNice catch! Didn't think of that.\n\n> Lastly, we have a convenient session-only checkbox to temporarily \n> disable\n> wrapping for a commit that does not persist across restarts.  The idea\n> is that sometimes you might use the GUI for a one-off commit where you\n> want to disable the wrapping for whatever reason, but don't want to\n> change your configuration.\n\nSounds like a good idea, but I wonder how we can fit it into git-gui's \ncurrent UI layout.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"382149","messageId":"20190910202823.hifl7mivwm6yaewy@yadavpratyush.com","threadId":"51802","inReplyTo":"62ef03a2938ac0d2158b1c3201c7f10e52e30ecb.1567627609.git.bert.wesarg@googlemail.com","subject":"Re: [PATCH 2/2] git-gui: add horizontal scrollbar to commit buffer","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-09-10T20:28:23Z","receivedAt":"2019-09-10T20:28:30Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 04/09/19 10:10PM, Bert Wesarg wrote:\n> While the commit message widget has a configurable fixed width, it\n> nevertheless allows to write commit messages which exceed this limit.\n> Though it does not show this content because there is not scrollbar for\n\nLike we discussed before, it does show the content, you just have to \nscroll by keyboard, and can't scroll by mouse. So maybe reword this?\n\n> this widget. No it is.\n\nI pulled from your GitHub since you seem to have fixed this typo there.\n\n> There seems to be a bug in at least up to Tcl/Tk 8.6.8, which does not\n> update the horizontal scrollbar if one removes the whole content at once.\n> \n> Suggested-by: Birger Skogeng Pedersen <birger.sp@gmail.com>\n> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n> ---\n>  git-gui.sh | 10 ++++++++--\n>  1 file changed, 8 insertions(+), 2 deletions(-)\n> \n> diff --git a/git-gui.sh b/git-gui.sh\n> index a491085..fa9c0d2 100755\n> --- a/git-gui.sh\n> +++ b/git-gui.sh\n> @@ -3363,14 +3363,20 @@ ttext $ui_comm -background white -foreground black \\\n>  \t-relief sunken \\\n>  \t-width $repo_config(gui.commitmsgwidth) -height 9 -wrap none \\\n>  \t-font font_diff \\\n> +\t-xscrollcommand {.vpane.lower.commarea.buffer.frame.sbx set} \\\n>  \t-yscrollcommand {.vpane.lower.commarea.buffer.frame.sby set}\n> +${NS}::scrollbar .vpane.lower.commarea.buffer.frame.sbx \\\n> +\t-orient horizontal \\\n> +\t-command [list $ui_comm xview]\n>  ${NS}::scrollbar .vpane.lower.commarea.buffer.frame.sby \\\n> +\t-orient vertical \\\n>  \t-command [list $ui_comm yview]\n>  \n> +pack .vpane.lower.commarea.buffer.frame.sbx -side bottom -fill x\n>  pack .vpane.lower.commarea.buffer.frame.sby -side right -fill y\n> -pack $ui_comm -side left -fill y\n> +pack $ui_comm -side left -fill both -expand 1\n\nDropping this change does not seem to make a difference. The commit \nmessage buffer expands on resize even without it. Can you please explain \nwhy you did this?\n\n>  pack .vpane.lower.commarea.buffer.header -side top -fill x\n> -pack .vpane.lower.commarea.buffer.frame -side left -fill y\n> +pack .vpane.lower.commarea.buffer.frame -side bottom -fill both -expand 1\n\nI'm not too familiar with pack, but why did you change the side from \nleft to bottom? I tested by changing it back to left and didn't notice \nany difference.\n\n>  pack .vpane.lower.commarea.buffer -side left -fill y\n>  \n>  # -- Commit Message Buffer Context Menu\n\nOther than these couple of minor things, the patch LGTM. Thanks.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"382150","messageId":"20190910203456.te2onnr3eibw2pjn@yadavpratyush.com","threadId":"51802","inReplyTo":"7da71d89f9fa987eca2e25974e4cec382c146e44.1567627609.git.bert.wesarg@googlemail.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Pratyush Yadav","fromEmail":"me@yadavpratyush.com","sentAt":"2019-09-10T20:34:57Z","receivedAt":"2019-09-10T20:35:02Z","isPatch":true,"sender":{"key":"me@yadavpratyush.com","avatar":"https://avatars.githubusercontent.com/u/8817931?v=4"},"body":"On 04/09/19 10:10PM, Bert Wesarg wrote:\n> The commit message widget does not wrap the next and has a configurable\n> fixed width to avoid creating too wide commit messages. Though this was\n> only enforced in the GUI. Now we also check the commit message at commit\n> time for long lines and ask the author for confirmation if it exceeds the\n> configured line length.\n\nThanks for the patch, but I'm not a big fan of this. I agree with Eric \nthat more dialogs are annoying. Even as a temporary change until we have \nword wrap support, I don't like it. I hope you don't mind if I only take \nthe scrollbar change and drop this.\n\n-- \nRegards,\nPratyush Yadav\n"},{"id":"382242","messageId":"CAKPyHN16Ogz-MXx-W+LGnaHwOjhyC1awQneozzzt0tDdCszWGw@mail.gmail.com","threadId":"51802","inReplyTo":"20190910202823.hifl7mivwm6yaewy@yadavpratyush.com","subject":"Re: [PATCH 2/2] git-gui: add horizontal scrollbar to commit buffer","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-12T19:10:13Z","receivedAt":"2019-09-12T19:10:27Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Sep 10, 2019 at 10:28 PM Pratyush Yadav <me@yadavpratyush.com> wrote:\n>\n> On 04/09/19 10:10PM, Bert Wesarg wrote:\n> > While the commit message widget has a configurable fixed width, it\n> > nevertheless allows to write commit messages which exceed this limit.\n> > Though it does not show this content because there is not scrollbar for\n>\n> Like we discussed before, it does show the content, you just have to\n> scroll by keyboard, and can't scroll by mouse. So maybe reword this?\n>\n> > this widget. No it is.\n>\n> I pulled from your GitHub since you seem to have fixed this typo there.\n>\n> > There seems to be a bug in at least up to Tcl/Tk 8.6.8, which does not\n> > update the horizontal scrollbar if one removes the whole content at once.\n> >\n> > Suggested-by: Birger Skogeng Pedersen <birger.sp@gmail.com>\n> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n> > ---\n> >  git-gui.sh | 10 ++++++++--\n> >  1 file changed, 8 insertions(+), 2 deletions(-)\n> >\n> > diff --git a/git-gui.sh b/git-gui.sh\n> > index a491085..fa9c0d2 100755\n> > --- a/git-gui.sh\n> > +++ b/git-gui.sh\n> > @@ -3363,14 +3363,20 @@ ttext $ui_comm -background white -foreground black \\\n> >       -relief sunken \\\n> >       -width $repo_config(gui.commitmsgwidth) -height 9 -wrap none \\\n> >       -font font_diff \\\n> > +     -xscrollcommand {.vpane.lower.commarea.buffer.frame.sbx set} \\\n> >       -yscrollcommand {.vpane.lower.commarea.buffer.frame.sby set}\n> > +${NS}::scrollbar .vpane.lower.commarea.buffer.frame.sbx \\\n> > +     -orient horizontal \\\n> > +     -command [list $ui_comm xview]\n> >  ${NS}::scrollbar .vpane.lower.commarea.buffer.frame.sby \\\n> > +     -orient vertical \\\n> >       -command [list $ui_comm yview]\n> >\n> > +pack .vpane.lower.commarea.buffer.frame.sbx -side bottom -fill x\n> >  pack .vpane.lower.commarea.buffer.frame.sby -side right -fill y\n> > -pack $ui_comm -side left -fill y\n> > +pack $ui_comm -side left -fill both -expand 1\n>\n> Dropping this change does not seem to make a difference. The commit\n> message buffer expands on resize even without it. Can you please explain\n> why you did this?\n>\n> >  pack .vpane.lower.commarea.buffer.header -side top -fill x\n> > -pack .vpane.lower.commarea.buffer.frame -side left -fill y\n> > +pack .vpane.lower.commarea.buffer.frame -side bottom -fill both -expand 1\n>\n> I'm not too familiar with pack, but why did you change the side from\n> left to bottom? I tested by changing it back to left and didn't notice\n> any difference.\n>\n> >  pack .vpane.lower.commarea.buffer -side left -fill y\n> >\n> >  # -- Commit Message Buffer Context Menu\n>\n> Other than these couple of minor things, the patch LGTM. Thanks.\n\nWill re-roll.\n\nThanks.\n\n>\n> --\n> Regards,\n> Pratyush Yadav\n"},{"id":"382243","messageId":"CAKPyHN3OX6cjc7-mLnOCfRKnNBdGUYsgbQQYiCw9GJravUkhvg@mail.gmail.com","threadId":"51802","inReplyTo":"20190910203456.te2onnr3eibw2pjn@yadavpratyush.com","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-12T19:13:34Z","receivedAt":"2019-09-12T19:13:47Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Sep 10, 2019 at 10:35 PM Pratyush Yadav <me@yadavpratyush.com> wrote:\n>\n> On 04/09/19 10:10PM, Bert Wesarg wrote:\n> > The commit message widget does not wrap the next and has a configurable\n> > fixed width to avoid creating too wide commit messages. Though this was\n> > only enforced in the GUI. Now we also check the commit message at commit\n> > time for long lines and ask the author for confirmation if it exceeds the\n> > configured line length.\n>\n> Thanks for the patch, but I'm not a big fan of this. I agree with Eric\n> that more dialogs are annoying. Even as a temporary change until we have\n> word wrap support, I don't like it. I hope you don't mind if I only take\n> the scrollbar change and drop this.\n\nNo problem, will keep this patch as a branch. Just wanted to be pro-active.\n\nBert\n\n\n>\n> --\n> Regards,\n> Pratyush Yadav\n"},{"id":"382245","messageId":"CAKPyHN0gX087_-tn=Q7gt7dJJaFg5idgz-E8zfTfRQxkCZb57A@mail.gmail.com","threadId":"51802","inReplyTo":"01e3c41d-af69-f9b3-31e6-12192e566f92@kdbg.org","subject":"Re: [PATCH 1/2] git-gui: warn if the commit message contains lines longer than the set limit","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2019-09-12T19:26:22Z","receivedAt":"2019-09-12T19:26:35Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Sep 10, 2019 at 6:50 PM Johannes Sixt <j6t@kdbg.org> wrote:\n>\n> Am 04.09.19 um 22:10 schrieb Bert Wesarg:\n> > The commit message widget does not wrap the next and has a configurable\n> > fixed width to avoid creating too wide commit messages. Though this was\n> > only enforced in the GUI. Now we also check the commit message at commit\n> > time for long lines and ask the author for confirmation if it exceeds the\n> > configured line length.\n> >\n> > Needs Tcl 8.6 because of `lmap`.\n> >\n> > Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n> > ---\n> >  git-gui.sh     |  4 ++--\n> >  lib/commit.tcl | 10 ++++++++++\n> >  2 files changed, 12 insertions(+), 2 deletions(-)\n> >\n> > diff --git a/git-gui.sh b/git-gui.sh\n> > index 5bc21b8..a491085 100755\n> > --- a/git-gui.sh\n> > +++ b/git-gui.sh\n> > @@ -31,8 +31,8 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA}]\n> >  ##\n> >  ## Tcl/Tk sanity check\n> >\n> > -if {[catch {package require Tcl 8.4} err]\n> > - || [catch {package require Tk  8.4} err]\n> > +if {[catch {package require Tcl 8.6} err]\n> > + || [catch {package require Tk  8.6} err]\n> >  } {\n> >       catch {wm withdraw .}\n> >       tk_messageBox \\\n> > diff --git a/lib/commit.tcl b/lib/commit.tcl\n> > index 83620b7..fa9760b 100644\n> > --- a/lib/commit.tcl\n> > +++ b/lib/commit.tcl\n> > @@ -215,6 +215,16 @@ A good commit message has the following format:\n> >               unlock_index\n> >               return\n> >       }\n> > +     if {[tcl::mathfunc::max {*}[lmap x [split $msg \"\\n\"] {string length $x}]] >= $repo_config(gui.commitmsgwidth) \\\n>\n> This has an off-by-one error: When I fill the edit box to the limit, but\n> not beyond it, I get the warning popup. I guess this should be '>', not\n> '>='.\n\nThanks. As Pratyush wont pull this one, I separated it and keep it in\na branch in my fork:\n\nhttps://github.com/bertwesarg/git-gui/tree/bw/warn-wide-commit-message\n\nBert\n\n>\n> > +         && [ask_popup \"Commit message contains lines longer than $repo_config(gui.commitmsgwidth) characters.\n> > +\n> > +You may change this limit in the options.\n> > +\n> > +Continue to commit?\n> > +\"] ne yes} {\n> > +             unlock_index\n> > +             return\n> > +     }\n> >\n> >       # -- Build the message file.\n> >       #\n> >\n>\n> -- Hannes\n"}]}