call external editor from git-gui?

git-gui is very good at composing commits. But for writing the actual commit message -- especially if it's long and needs paragraph reflowing, indentation, and so on -- I vastly prefer emacs over git-gui's text field.

It seems to me like it would be straightforward to have a button or something to launch the user's favorite editor for editing of the commit message -- after all, git even knows what editor that is!

Unfortunately, with my tcl expertise, this is likely a whole-weekend project, so I probably won't try to build it myself in the near future.

Karl Hasselstrm <kha@treskal.com> wrote:

Yea, I've been thinking about adding fancy features like those.
But been lazy.  Spawning the user's preferred editor would be a
nice way to get some of that.
 

Probably. git-gui already has the data from .git/config loaded in memory, it should be fairly simple.

With my busy schedule its unlikely to happen anytime soon either. But I've added it to my todo branch. Sometimes things on that list get accomplished. ;-)

An annoying work-around would be to run your editor to create/edit .git/GITGUI_MSG (or .git/MERGE_MSG) then hit Rescan in git-gui. It loads that file into its editor buffer if the editor buffer is empty or has not been modified from within git-gui since the last time the file was read.

On 2007-08-14 00:55:11 -0400, Shawn O. Pearce wrote:

Yeah, every time I read the git list, I think to myself, "Wow, Shawn sure is lazy!" :-)

You do a lot of seriously useful work on git.

Mmm. I wouldn't call it a _nice_ way: popping up an external program just to get the right text editing behavior. More like the _only_ way, if the user is picky enough.

I just tend to git-commit --amend to accomplish that.

On Tue, Aug 14, 2007 at 09:00:00 +0200, Karl Hasselström wrote:

It might actually have a rather serious twist. Often the editor for git-commit would use the terminal git-commit runs on. But for git-gui you may not have any terminal (running git-gui from context menu of some file manager) and even if you do, the user does not expect it to be used. So the user may -- and quite often will -- want different editors for running from git-gui and git-commit.

Hello,

Jan Hudec wrote:

Alternatively you need to find out/let the user specify if her editor needs a terminal and then use

	xterm -e myfavoriteeditor

or simply

	myfavoriteeditor

depending on the result.

Best regards Uwe

Jan Hudec <bulb@ucw.cz> writes:

The usual convention (though _very_ hard to find anywhere explicitly, so it might more often than not be ignored) is that $VISUAL points to an editor that requires a tty to work on, while $EDITOR might get along without one.

So one uses VISUAL in preference of EDITOR on ttys/proper terminals, but only EDITOR when without one. A call from git-gui would probably fall in the second category. A call from tig, in contrast, in the first category.

The GIT_EDITOR variable has no way of expressing this difference, though. And I doubt that many people remember this. I googled around but failed to come up with a useful reference (of course, both variable names being common words does not exactly help).

It seems quite common to have a trio of environment variables: $EDITOR, $VISUAL and $XEDITOR, for line, tty-aware and graphical editors respectively.

[http://xdvi.sourceforge.net/inverse-search-emacs-noauctex.html] [http://lists.osuosl.org/pipermail/darcs-users/2006-December/010783.html]

Whether git needs to have a trio of overrides for them is a different matter, or could just recommend that git be aliased or wrapped if the editors needed for git are different to normal.

Cheers, Mike

On 8/15/07, David Kastrup <dak@gnu.org> wrote: