call external editor from git-gui?

call external editor from git-gui?

[Karl Hasselström]

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

Re: call external editor from git-gui?

[Shawn O. Pearce]

Karl Hasselstrm <kha@treskal.com> 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.

Re: call external editor from git-gui?

[Karl Hasselström]

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

> Karl Hasselstrm <kha@treskal.com> 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.

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

Re: call external editor from git-gui?

[Jan Hudec]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

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:
> > 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 <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: call external editor from git-gui?

[Uwe Kleine-König]

Hello,

Jan Hudec wrote:
> 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:
> > > 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"

Re: call external editor from git-gui?

[David Kastrup]

Jan Hudec <bulb@ucw.cz> writes:

> 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:
>> > 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

Re: call external editor from git-gui?

[Mike Ralphson]

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