From: Bert Wesarg Date: Fri, 19 Nov 2010 12:15:44 GMT Subject: Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype Message-ID: In-Reply-To: <20101114234848.GB26104@burratino> On Mon, Nov 15, 2010 at 00:48, Jonathan Nieder 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