using gvim as editor on Windows

using gvim as editor on Windows

[Tait]

I'd prefer to use gvim as an editor on Windows XP instead of vim. (I also
prefer it as a difftool, but that's a separate issue.) Gvim releases
the terminal when it launches, which git doesn't like too much. So I
create gvimf.cmd in my path and use it for core.editor. Gvimf.cmd is
quite simple; it calls:
	start "dummy" /b /wait "C:\Program Files\Vim\vim72\gvim.exe" %*

In .gitconfig:
[core]
	editor = gvimf.cmd

This works well enough for git commit. However, git rebase -i is not
happy. It errors:
	C:\path to\repo> git rebase -i HEAD~10
	The system cannot find the file dummy.
	Could not execute editor

Okay, I can fix that. I change core.editor to "cmd \\/c gvimf.cmd". (This
is the same pattern I use for gvim as a difftool.) Now my .gitconfig has:
[core]
	editor = cmd \\\\/c gvimf.cmd

Git rebase is happy, but git commit is not. It errors:
	C:\path to\repo> git commit
	'OMMIT_EDITMSG' is not recognized as an internal or external command,
	operable program or batch file.
	error: There was a problem with the editor 'cmd \\/c gvimf.cmd'.
	Please supply the message using either -m or -F option.

In the selfish hope to avoid work, has anyone else already encountered
and solved how to use gvim as an editor?

Tait

Re: using gvim as editor on Windows

[Jacob Helwig]

On Fri, Mar 5, 2010 at 23:06, Tait <git.git@t41t.com> wrote:
>
> I'd prefer to use gvim as an editor on Windows XP instead of vim. (I also
> prefer it as a difftool, but that's a separate issue.) Gvim releases
> the terminal when it launches, which git doesn't like too much. So I
> create gvimf.cmd in my path and use it for core.editor. Gvimf.cmd is
> quite simple; it calls:
>        start "dummy" /b /wait "C:\Program Files\Vim\vim72\gvim.exe" %*
>
> In .gitconfig:
> [core]
>        editor = gvimf.cmd
>
> This works well enough for git commit. However, git rebase -i is not
> happy. It errors:
>        C:\path to\repo> git rebase -i HEAD~10
>        The system cannot find the file dummy.
>        Could not execute editor
>
> Okay, I can fix that. I change core.editor to "cmd \\/c gvimf.cmd". (This
> is the same pattern I use for gvim as a difftool.) Now my .gitconfig has:
> [core]
>        editor = cmd \\\\/c gvimf.cmd
>
> Git rebase is happy, but git commit is not. It errors:
>        C:\path to\repo> git commit
>        'OMMIT_EDITMSG' is not recognized as an internal or external command,
>        operable program or batch file.
>        error: There was a problem with the editor 'cmd \\/c gvimf.cmd'.
>        Please supply the message using either -m or -F option.
>
> In the selfish hope to avoid work, has anyone else already encountered
> and solved how to use gvim as an editor?
>
> Tait
>

Use the -f (stay in the foreground) flag.  I haven't tried this in
Windows, but that's how I've used it in Linux.

[core]
    editor = gvim -f

Re: using gvim as editor on Windows

[Tait]

> > I'd prefer to use gvim as an editor on Windows XP instead of vim...
> >     start "dummy" /b /wait "C:\Program Files\Vim\vim72\gvim.exe" %*
>
> Use the -f (stay in the foreground) flag.  I haven't tried this in
> Windows, but that's how I've used it in Linux.
>
> [core]
>     editor = gvim -f

On Windows, gvim -f is basically a shortcut for the start invocation I
pasted above. It works well enough for commit, but not for rebase (or
alternately, for rebase -- so long as it doesn't open an editor for git
commit -- but not commit).

Tait

Re: using gvim as editor on Windows

[Markus Heidelberg]

Tait, 2010-03-06 08:37:
> > > I'd prefer to use gvim as an editor on Windows XP instead of vim...
> > >     start "dummy" /b /wait "C:\Program Files\Vim\vim72\gvim.exe" %*
> >
> > Use the -f (stay in the foreground) flag.  I haven't tried this in
> > Windows, but that's how I've used it in Linux.
> >
> > [core]
> >     editor = gvim -f
> 
> On Windows, gvim -f is basically a shortcut for the start invocation I
> pasted above.

Not necessarily. You can avoid using the .bat wrappers from C:\Windows,
which cause the problem, but use gvim.exe directly by setting your PATH
appropriately. It will also work for git-difftool.

Markus

Re: using gvim as editor on Windows

[Tait]

> > On Windows, gvim -f is basically a shortcut for the start invocation I
> > pasted above.
>
> Not necessarily. You can avoid using the .bat wrappers from C:\Windows,
> which cause the problem, but use gvim.exe directly by setting your PATH
> appropriately. It will also work for git-difftool.

I was hoping for a little more life in this thread.

Does calling the .exe directly work for you? If I call gvim.exe directly
(with or without -f -- it doesn't matter), it opens a new file called
$@. After quitting, the commit is aborted for lack of a commit message. I
can do an ugly work-around by making core.editor "gvim.exe -f $@" but
then gvim opens two buffers, one for the commit message and another for
the literal $@.

With rebase -i, calling the executable directly (with or without -f)
works to open the commit list. Rebase -i with $@ in the setting fails. It
appears the filename is not quoted correctly and vim is opening multiple
buffers with various components of the path name as filenames.

The problem seems to be unique to me, so I'll find some time to look at
what rebase and/or commit are doing wrong.

Tait

Re: using gvim as editor on Windows

[Markus Heidelberg]

Tait, 2010-03-08 19:54:
> > > On Windows, gvim -f is basically a shortcut for the start invocation I
> > > pasted above.
> >
> > Not necessarily. You can avoid using the .bat wrappers from C:\Windows,
> > which cause the problem, but use gvim.exe directly by setting your PATH
> > appropriately. It will also work for git-difftool.
> 
> I was hoping for a little more life in this thread.

First of all: do you have the problems in cmd.exe or Git Bash or both?

> Does calling the .exe directly work for you? If I call gvim.exe directly
> (with or without -f -- it doesn't matter), it opens a new file called
> $@.

I don't know where the $@ should come from. You apparently don't invoke
gvim.exe directly. git-commit is a C program, not a shell script, there
should come no $@ from this side. What does invoking gvim.exe on the
command line without the use of git do?

I have:
core.editor=gvim -f
C:\Programme\Vim\vim72 in PATH (both before or after C:\WINDOWS works here)
Works with cmd.exe and Git Bash.

> The problem seems to be unique to me, so I'll find some time to look at
> what rebase and/or commit are doing wrong.

I guess neither rebase nor commit are wrong in this case.

Markus

Re: using gvim as editor on Windows

[Tait]

> First of all: do you have the problems in cmd.exe or Git Bash or both?

cmd.exe

I've never used git bash until now, but the behavior is the same there.

> > Does calling the .exe directly work for you? If I call gvim.exe directly
> > (with or without -f -- it doesn't matter), it opens a new file called
> > $@.
> 
> I don't know where the $@ should come from.

It comes from line 33 of editor.c, in launch_editor().
if (strcmp(editor, ":")) {
    /* ... */
    if (strcspn(editor, "$ \t'") != len) {
        /* there are specials */
        strbuf_addf(&arg0, "%s \"$@\"", editor);
        args[i++] = "sh";
        args[i++] = "-c";
        args[i++] = arg0.buf;
    }
    args[i++] = editor;
    args[i++] = path;
    args[i] = NULL;
    /* ... */
}

It looks like this was added to detect EDITOR=: but it also
manages to catch Windows paths. I'm not familiar with the EDITOR=:
convention. What is that supposed to indicate? Can we narrow the
detection to that specific case, or does a : anywhere in EDITOR need
to be handled this way?

Rebase doesn't use launch_editor, instead just calling the editor
directly. Coming up with a combination of quoting and escaping that
can pass both cases will be difficult or impossible.

It appears that e97c9a removed the code above from editor.c, but 
it's still present in prepare_shell_cmd() with even more legal 
filename characters like = and ;.

Thanks for the help Markus.

Tait

Re: using gvim as editor on Windows

[Junio C Hamano]

Tait <git.git@t41t.com> writes:

> It comes from line 33 of editor.c, in launch_editor().
> if (strcmp(editor, ":")) {

This says "if 'editor' is not exactly the string ':'", then come into this
block.  If you set editor to ":abc", or "c:\path to\my editor.exe", they
are not "exactly the string ':'" and the codepath inside will be executed.

> ... I'm not familiar with the EDITOR=:
> convention. What is that supposed to indicate?

Literally, it means "run ':' command as the editor".  ':' command takes
and ignores arbitrary arguments and returns success without doing
anything.  As such, the codepath pretends that it ran ':' command without
actually running it, and returns as if it ran ':' command that left the
input file given as its argument unmodified.

> Can we narrow the
> detection to that specific case, or does a : anywhere in EDITOR need
> to be handled this way?

No, and the if statement is already narrow enough.  I think the problem is
that you have a broken shell ("sh").

    /* ... */
    if (strcspn(editor, "$ \t'") != len) {
        /* there are specials */
        strbuf_addf(&arg0, "%s \"$@\"", editor);
        args[i++] = "sh";
        args[i++] = "-c";
        args[i++] = arg0.buf;
    }
    args[i++] = editor;
    args[i++] = path;
    args[i] = NULL;
    /* ... */


If you have editor='"c:\some path\editor" -f', strcspn() notices that you have a
funny character in the path, and creates this string in arg0:

    "c:\some path\editor" -f "$@"

and feeds '-c', the above arg0, editor, and finally the name of the file,
to your shell; it is the same as running this from the command line:

    sh -c '"c:\some path\editor" -f "$@"' '"c:\some path\editor" -f' path-to-file

Now shell is supposed to expand "$@" into positional parameters, i.e. $1
(in this case, path-to-file) and run the named editor with it, IOW, your
editor program should see "-f" as its first parameter, and path-to-file as
its second parameter (and argv[] is terminated with NULL after that).

If you end up with a file whose name literally is '$@', that probably
means your "sh" did not expand it correctly.

Re: using gvim as editor on Windows

[Tait]

> This says "if 'editor' is not exactly the string ':'", ...

Oh right; I ... yeah, something. (I've got no excuse for mis-thinking
that one.)

> If you end up with a file whose name literally is '$@', that probably
> means your "sh" did not expand it correctly.

It does expand the $@ when I add it explicitly to core.editor though. Maybe
it's the ""s. I'll have to figure out how to compile git for Windows
to try a patch.

Oddly enough, if I remove the : from the file path, it does work as
expected. Adding the : back introduces the faulty behavior described
earlier.

Tait

Re: using gvim as editor on Windows

[Johannes Sixt]

Tait schrieb:
>> If you end up with a file whose name literally is '$@', that probably
>> means your "sh" did not expand it correctly.
> 
> It does expand the $@ when I add it explicitly to core.editor though. Maybe
> it's the ""s. I'll have to figure out how to compile git for Windows
> to try a patch.
> 
> Oddly enough, if I remove the : from the file path, it does work as
> expected. Adding the : back introduces the faulty behavior described
> earlier.

Which : are you talking about?

-- Hannes