[PATCH v2] Making utf-8 commit messages editable in vim

[Atsushi Nakagawa]

I've reworked the commit message to encompass more of the discussion and
added "git-rebase-todo" to the list of files to process.

Along with these emails, I've also uploaded the changes to here:
https://github.com/atnak/msysgit/tree/an/vim-utf-8

Migration:
Users with an exotic value for `i18n.commitencoding' have taken the back
seat. Although some consideration has been given, worst case scenario
is that they'll need to hand-edit share/vim/vimrc to regain legacy
behaviour.

For best outcome, `i18n.commitencoding' should be unset. Moving forward
(post unicode series), I don't think there's much sense, at this level,
in supporting compatibility with customized `i18n.commitencoding', if it
means it's going to affect standard users negatively.

Atsushi Nakagawa (1):
vimrc: Set UTF-8 as vim's default encoding for commit messages

share/vim/vimrc | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

--
Atsushi Nakagawa
<at...@chejz.com>
Changes are made when there is inconvenience.

[Atsushi Nakagawa]

We avoid setting `encoding' and `termencoding', and opt to only setting
`fileencodings' because it's understood that vim sets the former two to
the user's system's "ANSI" and "OEM" code pages (setting either both if
they differ or only `encoding' if they're the same) [1]. The setting of
"OEM" is particularly significant as it is required for native characters
to be correctly displayed on the user's console [2].

We set "utf-8" as the only value of `fileencodings', there by making it
the default encoding used to save new commit messages to COMMIT_EDITMSG.
This is consistent with what git expects in an environment where the
user has not altered the value of `i18n.commitencoding'.

When loading an existing message, for operations such as 'commit --amend'
and 'rebase -i', our setting for `fileencodings' means that vim will first
attempt to load it as UTF-8 and then fallback to the encoding set by
`encoding' if unable to do so. This encoding is expected to be "ANSI",
as mentioned above, and this side-effect is of benefit if the user does
have an altered value of `i18n.commitencoding'. (Here, we're assuming
users not set this, if at all, to anything other than that of "ANSI"
because that is thought to be the most natural for their location.)

Users SHOULD unset `i18n.commitencoding' after this is released. However,
failing to do so may not show any visible regressions. (See tests for
case #2 at [3].)

This patch follows the discussion in the [4] link.

[1] http://groups.google.com/group/msysgit/msg/be6218f1cbf5e747
[2] http://groups.google.com/group/vim_dev/msg/3dd77f3014a60e43
[3] http://groups.google.com/group/msysgit/msg/508cca8b57f00546
[4] http://groups.google.com/group/msysgit/msg/55c582fb1b279d08

Signed-off-by: Atsushi Nakagawa <at...@chejz.com>
---

share/vim/vimrc | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/share/vim/vimrc b/share/vim/vimrc
index 0d8cd4d..941ebba 100644
--- a/share/vim/vimrc
+++ b/share/vim/vimrc
@@ -17,6 +17,9 @@ set statusline=%<%F%h%m%r\ [%{&ff}]\ (%{strftime(\"%H:%M\ %d/%m/%Y\",getftime(ex
"------------------------------------------------------------------------------
" Only do this part when compiled with support for autocommands.
if has("autocmd")
+ "Set UTF-8 as the default encoding for commit messages
+ autocmd BufReadPre COMMIT_EDITMSG,git-rebase-todo setlocal fileencodings=utf-8
+
"Remember the positions in files with some git-specific exceptions"
autocmd BufReadPost *
\ if line("'\"") > 0 && line("'\"") <= line("$")