TL;DR: it does this by generating shell aliases which use $EDITOR to open the file. Neat, but does it clean up the aliases when you use one? And what if you don't use any? Kinda makes my OCD cringe a bit.
[alias]
grepgvim = "!f() { git grep -l \"$@\" | xargs gvim -p; }; f"
It seems "Tag" is a little fancier in that it lets you go to specific matching lines, for the specific match. Tag is a command-line equivalent to `git cola grep <pattern>`, where you can select the matches visually in a GUI (with keyboard shortcuts) and then launch $EDITOR (e.g. gvim) on the matching line.To the Tag author, maybe users would find this tidier if `tag` let you edit matches directly by invoking e.g. `tag func -e 96` and tag will do the rest?
In such a scheme someone could even set the alias file to `/dev/null` and it'd allow both the current workflow and a new one that didn't rely on aliases.
EDITOR="FOO"
$EDITOR $FILE
Are there issues with this? I can't imagine a reason they'd need to export $EDITOR to the parent shell process. ~/badcode$ echo "func" > badfile.go\;\ echo\ \"Gotcha\!\"
~/badcode$ ls
badfile.go; echo "Gotcha!"
~/badcode$ tag func
badfile.go; echo "Gotcha!"
[1] 1:func
~/badcode$ e1
Gotcha! +1
In case that's not clear, I was able to create a file with a name that contains potentially malicious shell commands that is now bound to an alias via tag.Other ways to implement the shortcuts: create a flag or subcommand to look up an hit from the results file and jump to it (I can alias this command to suit my taste) or prompt me for input before returning to the command line.