From: Bert Wesarg <bert.wesarg@googlemail.com>
Date: Sun, 14 Nov 2010 22:15:12 GMT
Subject: Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype
Message-ID: <AANLkTi=JR3vVnZ4Yz8o9MpZKiQ2_ASYxahbPNv8QACir@mail.gmail.com>
In-Reply-To: <20101114220932.GE16413@burratino>

On Sun, Nov 14, 2010 at 23:09, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Bert Wesarg wrote:
>> On Sun, Nov 14, 2010 at 22:54, Jonathan Nieder <jrnieder@gmail.com> 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