On Sun, Nov 14, 2010 at 23:09, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Bert Wesarg wrote: >> On Sun, Nov 14, 2010 at 22:54, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > >>> This sounds like an excellent sort of thing to add to git grep -O, too >>> (which currently has very limited support for editors' line number >>> features). ÂBut what will it do with typical non-git-specific setups >>> like >>> >>> Â Â Â ÂVISUAL=vim >>> >>> or >>> >>> Â Â Â ÂEDITOR="gvim --nofork" >>> >>> ? >>> >>> Do existing editors support LINENUMBER in the environment? >> >> I don't expect this, I have a wrapper script around my editor to scan >> the environment for these variables and pass the block/non-block >> option to the editor. > > In that case, perhaps something like > > Â Â Â ÂGIT_EDITOR=$(git var GIT_EDITOR) > Â Â Â Âset -- --open-file-named-in-the-environment > Â Â Â Âeval "$GIT_EDITOR" '"$@"' > > would be appropriate? ÂThis way, existing editors like vi, ed, and > emacs fail: > > Â Â Â Â$ ed --fjdkaslfjdas > Â Â Â Âed: unrecognized option `--fjdkaslfjdas' > > rather than opening a new, empty file. > Now I got your point. Maybe I should call GIT_EDITOR with $FILENAME as argument but with a new variable to indicate open'n'forget. So existing setups would always open the file (even without honoring the line number) and new/smart wrappers can honor the open'n'forget and line number flag. Bert -- 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