On Mon, Oct 12, 2009 at 5:25 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: >> On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: >> > >> > Someone needs to whack gvim upside the head and fix that program >> > to behave correctly. >> >> Huh? What is wrong about 'gvim --nofork'? > > The fact that its a command line option that isn't the default. > gvim's UI here is as bad as pre 0.99 git. > > People do: > > export EDITOR=gvim > > and things work OK for a while, as they always open a new editor, > work with the file, and then close it, killing the only running gvim > session. Since gvim waits if its the only gvim process running, > things seem fine. But days later when you leave a file open, > suddenly the command calling $EDITOR starts failing. I've never seen it happening. For me either it aways fails (fork) or always work (nofork). > I've seen it happen to a lot of people. They just start complaining > about how one day "git commit" is fine, and the next day its > not working. But its been weeks since they selected gvim as their > $EDITOR and they can't connect the open editor window as the problem > with that Goddamn Idiotic Truckload of s**t they are forced to use. Yeah, it happened to me too, but eventually I realized what was happening. I like gvim's default behavior tough. I personally don't see any problem... how about other SCMs? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html