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 Hasselström, kha@treskal.com
      www.treskal.com/kalle

Karl Hasselstrm [off-list ref] wrote:

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.

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.
 

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!

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

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.

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.

-- 
Shawn.

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

Karl Hasselstrm [off-list ref] wrote:

quoted

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.

Yea, I've been thinking about adding fancy features like those. But
been lazy.

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.

Spawning the user's preferred editor would be a nice way to get some
of that.

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.

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.

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

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

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

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

quoted

Spawning the user's preferred editor would be a nice way to get some
of that.

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.

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.

-- 
						 Jan 'Bulb' Hudec [off-list ref]

Hello,

Jan Hudec wrote:

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

quoted

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

quoted

Spawning the user's preferred editor would be a nice way to get some
of that.

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.

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.

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

-- 
Uwe Kleine-König

$ dc -e "5735816763073014741799356604682P"

Jan Hudec [off-list ref] writes:

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

quoted

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

quoted

Spawning the user's preferred editor would be a nice way to get some
of that.

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.

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.

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).

-- 
David Kastrup

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 [off-list ref] wrote:

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).