Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype

[Bert Wesarg <bert.wesarg@googlemail.com>]

On Mon, Nov 15, 2010 at 00:48, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Bert Wesarg wrote:
>
>> 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.
>
> Yes, I like the communication-via-environment idea.
>
> In fact, there are multiple questions an editor might want answered:
>
> 1. GUI or no GUI?  (The combination of $DISPLAY and $(tty) often
>   yields a reasonable answer.)

I think we can generalize this by using the name of the caller (ie
binary name). This is easy to get in a unix/linux shell with the help
of /proc/$PPID/exe, but maybe not so in others OS's. I just remembered
that quilt has this feature, the name is QUILT_COMMAND and I use is in
my wrapper script to detect whether the caller wants to wait or not (I
block only on the header and mail command).

>
> 2. open'n'forget or wait for answer?  (gvim's --nofork option)
>
> 3. What line number?
>
> 4. regex to use to highlight matches?
>
> Ideally $LINENUMBER would only be used represent (3), while a
> separate variable would indicate (2).
>

Using for each case its own flag may sound silly, but I think this
makes it more clear, what the caller expects.
For example in my git-patch for calling GIT_EDITOR I provide a flag
whether the given path is in the index or not (ie the action comes
from the index list). If it is from the index, I use checkout-index
--temp and update-index to edit the content from the index. This call
to GIT_EDITOR should be blocking but it is better to request this
explicitly.

Could we settle on a name space for such variables? GIT_EDITOR_* makes
it obvious that it is for the editor started from git.

Bert