wrong highliting in terminal on git-commit message
snitko
The commit message was always highlighted with white color, but
recently it has turned into this weird thing. The color scheme file
hasn't changed. How do I fix this?
Simon Ruderich
If you mean the orange color, this is a recommendation of Git; the short
commit message should only be 50 characters long, the rest is in white so you
know when you are past 50 characters.
The second line should always be empty so it's colored as error. The long
description starts in in the third line.
If you want to changes this, remove these lines from gitcommit.vim (my version
is from 2008 Apr 09).
hi def link gitcommitSummary Keyword
hi def link gitcommitBlank Error
Hope this helps,
Simon
--
+ privacy is necessary
+ using http://gnupg.org
+ public key id: 0x6115F804EFB33229
Matt Wozniski
> On Mon, Dec 01, 2008 at 04:11:29AM -0800, snitko wrote:
>> Here's a screenshot: http://dl.getdropbox.com/u/113891/pics/vim_commit_message.png
>> The commit message was always highlighted with white color, but
>> recently it has turned into this weird thing. The color scheme file
>> hasn't changed. How do I fix this?
>
> If you mean the orange color, this is a recommendation of Git; the short
> commit message should only be 50 characters long, the rest is in white so you
> know when you are past 50 characters.
>
> The second line should always be empty so it's colored as error. The long
> description starts in in the third line.
>
> If you want to changes this, remove these lines from gitcommit.vim (my version
> is from 2008 Apr 09).
>
> hi def link gitcommitSummary Keyword
> hi def link gitcommitBlank Error
Or, much nicer, adding
hi def link gitcommitSummary Normal
hi def link gitcommitBlank Normal
to your ~/.vimrc - same effect, but the changes won't be reverted next
time gitcommit.vim is upgraded.
~Matt
snitko
> If you want to changes this, remove these lines from gitcommit.vim (my version
> is from 2008 Apr 09).
>
> hi def link gitcommitSummary Keyword
> hi def link gitcommitBlank Error
I thought long description starts on the second line, actually. And,
btw, the red color there - it's not the second line. It's the same
first line, vim just automatically moved it to the next line, but
there's no \n symbols there.
Matt Wozniski
>
> Great, thank you. Btw, since when second line in git should be empty?
See man git-commit
DISCUSSION
Though not required, it´s a good idea to begin the commit message with
a single short (less than 50 character) line summarizing the change,
followed by a blank line and then a more thorough description.
Also, check out the gitcommit.vim author's blog post about the
rationale for this syntax file:
> I thought long description starts on the second line, actually. And,
> btw, the red color there - it's not the second line. It's the same
> first line, vim just automatically moved it to the next line, but
> there's no \n symbols there.
No, if it's highlighted in red, there must be a newline there. Vim
probably added it for you, thanks to 'textwidth' and 'formatoptions' -
the textwidth used for gitcommit is 72, which so vim would have
automatically wrapped that line - the last 'e' in "white" would be the
71st character on the line.
~Matt
Teemu Likonen
> On Mon, Dec 1, 2008 at 6:48 PM, snitko wrote:
>> Great, thank you. Btw, since when second line in git should be empty?
This may not be a "should" statement but in the git.git repository Linus
Torvalds had this practice since the day one (2005-04-07).
> See man git-commit
>
> DISCUSSION
> Though not required, it´s a good idea to begin the commit
> message with a single short (less than 50 character) line
> summarizing the change, followed by a blank line and then a
> more thorough description.
And a real-life example from git.git and linux-2.6.git repositories:
http://git.kernel.org/?p=git/git.git;a=log
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=log
Simon Ruderich
> Or, much nicer, adding
>
> hi def link gitcommitSummary Normal
> hi def link gitcommitBlank Normal
>
> to your ~/.vimrc - same effect, but the changes won't be reverted next
> time gitcommit.vim is upgraded.
>
> ~Matt
That is much better, thanks for the hint.
Tony Mechelynck
The above should appear in your vimrc after the ":colorscheme" command.
Alternately, you can use
hi ColorScheme * hi def link gitcommitSummary Normal
\ | hi def link gitcommitBlank Normal
(or any other link) in your vimrc before the ":colorscheme", to avoid
having them removed even if you change colorschemes after starting Vim,
and even if one of them uses "hi clear" before setting its own colors.
Best regards,
Tony.
--
"Intelligence has much less practical application than you'd think."
-- Scott Adams, Dilbert.
Matt Wozniski
> On 01/12/08 19:04, Matt Wozniski wrote:
>> On Mon, Dec 1, 2008 at 11:15 AM, Simon Ruderich wrote:
>>> If you want to changes this, remove these lines from gitcommit.vim (my version
>>> is from 2008 Apr 09).
>>>
>>> hi def link gitcommitSummary Keyword
>>> hi def link gitcommitBlank Error
>>
>> Or, much nicer, adding
>>
>> hi def link gitcommitSummary Normal
>> hi def link gitcommitBlank Normal
>>
>> to your ~/.vimrc - same effect, but the changes won't be reverted next
>> time gitcommit.vim is upgraded.
>
> Alternately, you can use
>
> hi ColorScheme * hi def link gitcommitSummary Normal
au
> \ | hi def link gitcommitBlank Normal
>
> (or any other link) in your vimrc before the ":colorscheme", to avoid
> having them removed even if you change colorschemes after starting Vim,
> and even if one of them uses "hi clear" before setting its own colors.
I don't think this is necessary - did you test it? It seems to me
that despite the fact that ":hi clear" is a :highlight command, it's
not cleared with :hi clear - in fact, it's shown with :syntax list
gitcommitBlank. I can find no way to make the "hi def link" in
~/.vimrc go wrong, and I tested with various combinations of "hi
clear" (it sticks around), "syn clear" (it disappears, but resetting
'syn' to 'gitcommit' brings it right back) and "colorscheme"...
Seems like the autocmd is unnecessary to me - and in fact, the vim
documentation itself seems to agree with me, see :help :hi-default
~Matt