{"thread":{"id":"25747","subject":"[PATCH/RFC/WIP/POC] git-gui: grep prototype","startedAt":"2010-11-14T21:41:09Z","lastAt":"2010-11-19T20:16:21Z","messageCount":9,"participants":["Bert Wesarg","Jonathan Nieder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"155882","messageId":"1289770869-11665-1-git-send-email-bert.wesarg@googlemail.com","threadId":"25747","inReplyTo":null,"subject":"[PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-11-14T21:41:09Z","receivedAt":"2010-11-14T21:41:09Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"This is a prototype gui to show the result from git grep.\n\nIt has a similar layout to git gui. That is, left is the list of matched files.\nAnd the right side shows the grep result for one file.\n\nThe prototype lives completely outside of git gui at the moment. The usage is:\n\n $ git-gui-grep.tcl [git-grep-match-options]\n\n-p and -C 3 are currently hard coded in the file. And you should also not\nuse any pathspecs after a --. Though, patchspecs without the -- separator\nmay work.\n\nThere is one feature that the upstream git gui lacks[1]: This grep gui can start\nthe git editor on every line by clicking with button 2 in the result area. The\ngit editor will than be started with the environment variable FILENAME and\nLINENUMBER set but no argument given. This makes it possible to distinguish\nbetween normal, blocking edit operation (like git commit) from this\nopen-and-forget type of operation.\n\nHow to proceed from this prototype isn't perfectly clear for me at the moment.\nI don't know if we need to enter/edit grep match options? If this should be a\nnew mode for git gui like blame and therefore in its one windows. I can imagine\nthat a tabbed interface would be nice for git gui. That would include having\na blame view inside a tab.\n\nSo any advice would be very welcome here.\n\nSigned-off-by: Bert Wesarg \n\n---\n\n[1]: I have done this for git-gui first, but it lacks the precise linenumber\n detection used here. Ie. I plan to add these line number columns to the\n diff view.\n\n git-gui-grep.tcl | 320 ++++++++++++++++++++++++++++++++++++++++++++++++++++++\n 1 files changed, 320 insertions(+), 0 deletions(-)\n\ndiff --git a/git-gui-grep.tcl b/git-gui-grep.tcl\nnew file mode 100755\nindex 0000000..fb61745\n--- /dev/null\n+++ b/git-gui-grep.tcl\n@@ -0,0 +1,320 @@\n+#!/bin/sh\n+# Tcl ignores the next line -*- tcl -*- \\\n+ argv0=$0; \\\n+ exec 'wish8.5' \"$argv0\" -- \"$@\"\n+\n+if {[catch {package require Tcl 8.5} err]\n+ || [catch {package require Tk 8.5} err]\n+} {\n+\tcatch {wm withdraw .}\n+\ttk_messageBox \\\n+\t\t-icon error \\\n+\t\t-type ok \\\n+\t\t-title \"git gui-grep: fatal error\" \\\n+\t\t-message $err\n+\texit 1\n+}\n+\n+proc scrollbar2many {list mode args} {\n+\tforeach w $list {eval $w $mode $args}\n+}\n+\n+proc many2scrollbar {list mode sb top bottom} {\n+\t$sb set $top $bottom\n+\tforeach w $list {$w $mode moveto $top}\n+}\n+\n+wm title . \"git gui-grep\"\n+\n+ttk::panedwindow .pane -orient horizontal\n+ttk::labelframe .pane.files -borderwidth 0 -text \"Matched files\"\n+ttk::labelframe .pane.out -borderwidth 0 -text \"Matches\"\n+.pane add .pane.files\n+.pane add .pane.out\n+\n+pack .pane -expand 1 -fill both\n+\n+text .pane.out.lnos \\\n+\t-takefocus 0 \\\n+\t-highlightthickness 0 \\\n+\t-padx 0 -pady 0 \\\n+\t-background white \\\n+\t-foreground black \\\n+\t-borderwidth 0 \\\n+\t-width 6 -height 25 \\\n+\t-wrap none \\\n+\t-state disabled\n+.pane.out.lnos tag conf linenumber -justify right -rmargin 5\n+bind .pane.out.lnos {open_from_grep_view .pane.out.lnos %x %y}\n+\n+text .pane.out.grep \\\n+\t-takefocus 0 \\\n+\t-highlightthickness 0 \\\n+\t-padx 0 -pady 0 \\\n+\t-background white \\\n+\t-foreground black \\\n+\t-borderwidth 0 \\\n+\t-width 80 -height 25 \\\n+\t-wrap none \\\n+\t-xscrollcommand {.pane.out.sx set} \\\n+\t-state disabled\n+.pane.out.grep tag conf match -foreground red\n+foreach {n c} {0 black 1 red4 2 green4 3 yellow4 4 blue4 5 magenta4 6 cyan4 7 grey60} {\n+\t.pane.out.grep tag configure clr4$n -background $c\n+\t.pane.out.grep tag configure clri4$n -foreground $c\n+\t.pane.out.grep tag configure clr3$n -foreground $c\n+\t.pane.out.grep tag configure clri3$n -background $c\n+}\n+bind .pane.out.grep {open_from_grep_view .pane.out.grep %x %y}\n+\n+set outcols [list .pane.out.lnos .pane.out.grep]\n+\n+ttk::scrollbar .pane.out.sx \\\n+\t-orient h \\\n+\t-command [list .pane.out.grep xview]\n+ttk::scrollbar .pane.out.sy \\\n+\t-orient v \\\n+\t-command [list scrollbar2many $outcols yview]\n+\n+grid .pane.out.lnos .pane.out.grep .pane.out.sy -sticky nsew\n+grid conf .pane.out.sx \\\n+\t-column 1 \\\n+\t-sticky we\n+grid columnconfigure .pane.out \\\n+\t1 \\\n+\t-weight 1\n+grid rowconfigure .pane.out \\\n+\t0 \\\n+\t-weight 1\n+\n+text .pane.files.list \\\n+\t-background white \\\n+\t-foreground black \\\n+\t-borderwidth 0 \\\n+\t-state disabled \\\n+\t-wrap none \\\n+\t-height 25 \\\n+\t-width 16 \\\n+\t-cursor arrow \\\n+\t-xscrollcommand [list .pane.files.sbx set] \\\n+\t-yscrollcommand [list .pane.files.sby set]\n+.pane.files.list tag raise sel\n+ttk::scrollbar .pane.files.sbx \\\n+\t-orient h \\\n+\t-command [list .pane.files.list xview]\n+ttk::scrollbar .pane.files.sby \\\n+\t-orient v \\\n+\t-command [list .pane.files.list yview]\n+pack .pane.files.sbx -side bottom -fill x\n+pack .pane.files.sby -side right -fill y\n+pack .pane.files.list -side left -expand 1 -fill both\n+bind .pane.files.list \"select_to_grep %x %y; break\"\n+\n+foreach i $outcols {\n+\t$i tag raise sel\n+\n+\t$i conf -cursor arrow\n+\t$i conf -yscrollcommand \\\n+\t\t\"[list many2scrollbar $outcols yview .pane.out.sy]\"\n+}\n+\n+proc escape_path {path} {\n+\tregsub -all {\\\\} $path \"\\\\\\\\\" path\n+\tregsub -all \"\\n\" $path \"\\\\n\" path\n+\treturn $path\n+}\n+\n+proc parse_color_line {line} {\n+\tset start 0\n+\tset result \"\"\n+\tset markup [list]\n+\tset regexp {\\033\\[((?:\\d+;)*\\d+)?m}\n+\twhile {[regexp -indices -start $start $regexp $line match code]} {\n+\t\tforeach {begin end} $match break\n+\t\tappend result [string range $line $start [expr {$begin - 1}]]\n+\t\tlappend markup [string length $result] \\\n+\t\t[eval [linsert $code 0 string range $line]]\n+\t\tset start [incr end]\n+\t}\n+\tappend result [string range $line $start end]\n+\tif {[llength $markup] < 4} {set markup {}}\n+\treturn [list $result $markup]\n+}\n+\n+\n+proc scan_grep {} {\n+\tglobal buf_rgl grep_patterns\n+\n+\tset buf_rgl {}\n+\tset cmd [concat [list | git grep -l -z] $grep_patterns]\n+\tif {[catch {set fd [open $cmd r]} err]} {\n+\t\ttk_messageBox \\\n+\t\t\t-icon error \\\n+\t\t\t-type ok \\\n+\t\t\t-title {git gui-grep: fatal error} \\\n+\t\t\t-message $err\n+\t\texit 1\n+\t}\n+\tfconfigure $fd -eofchar {}\n+\tfconfigure $fd \\\n+\t\t-blocking 0 \\\n+\t\t-buffering full \\\n+\t\t-buffersize 512 \\\n+\t\t-translation binary\n+\tfileevent $fd readable [list read_grep_l $fd]\n+}\n+\n+proc read_grep_l {fd} {\n+\tglobal buf_rgl grep_file_list grep_patterns current_grep_path\n+\n+\tappend buf_rgl [read $fd]\n+\tset pck [split $buf_rgl \"\\0\"]\n+\tset buf_rgl [lindex $pck end]\n+\n+\t.pane.files.list conf -state normal\n+\tforeach p [lrange $pck 0 end-1] {\n+\t\t#set p [encoding convertfrom $p]\n+\t\tif {[string index $p end] eq {/}} {\n+\t\t\tset p [string range $p 0 end-1]\n+\t\t}\n+\t\tlappend grep_file_list $p\n+\t\t.pane.files.list insert end \"[escape_path $p]\\n\"\n+\t}\n+\t.pane.files.list conf -state disabled\n+\n+\tif {![eof $fd]} return\n+\tset buf_rgl {}\n+\tclose $fd\n+\n+\tif {[llength $grep_file_list] eq 0} {\n+\t\texit 0\n+\t}\n+\tgrep_file [lindex $grep_file_list 0]\n+}\n+\n+proc grep_file {path} {\n+\tglobal outcols grep_patterns\n+\tset cmd [concat [list | git grep --color -h -n -p -3] $grep_patterns [list -- $path]]\n+\n+\tforeach i $outcols {\n+\t\t$i conf -state normal\n+\t\t$i delete 0.0 end\n+\t\t$i conf -state disabled\n+\t}\n+\n+\tif {[catch {set fd [open $cmd r]} err]} {\n+\t\ttk_messageBox \\\n+\t\t\t-icon error \\\n+\t\t\t-type ok \\\n+\t\t\t-title {gui-grep: fatal error} \\\n+\t\t\t-message $err\n+\t\texit 1\n+\t}\n+\tfconfigure $fd -eofchar {}\n+\tfconfigure $fd \\\n+\t\t-blocking 0 \\\n+\t\t-buffering full \\\n+\t\t-buffersize 512 \\\n+\t\t-translation lf\n+\tfileevent $fd readable [list read_grep $fd $path]\n+}\n+\n+proc read_grep {fd path} {\n+\tglobal outcols current_grep_path\n+\n+\tforeach i $outcols {$i conf -state normal}\n+\n+\tset l 0\n+\twhile {[gets $fd line] >= 0} {\n+\t\tincr l\n+\t\tif {$l > 1} {\n+\t\t\tforeach i $outcols {$i insert end \"\\n\"}\n+\t\t}\n+\n+\t\t# catch hunk sep --\n+\t\tif {[regexp {^(?:\\033\\[(?:(?:\\d+;)*\\d+)m)?--(?:\\033\\[m)?} $line]} {\n+\t\t\t.pane.out.lnos insert end \"--\" linenumber\n+\t\t\tcontinue\n+\t\t}\n+\n+\t\t# remove any color from lno and sep\n+\t\tregexp {^(?:\\033\\[(?:(?:\\d+;)*\\d+)m)?(\\d+)(?:\\033\\[m)?(?:\\033\\[(?:(?:\\d+;)*\\d+)m)?[-:=](?:\\033\\[m)?(.*)$} $line all lno mline\n+\t\tforeach {mline markup} [parse_color_line $mline] break\n+\t\tset mline [string map {\\033 ^} $mline]\n+\t\t#regsub \"\\r\\$\" $line {} line\n+\n+\t\tset mark [.pane.out.grep index \"end - 1 line linestart\"]\n+\n+\t\t.pane.out.lnos insert end $lno linenumber\n+\t\t.pane.out.grep insert end $mline\n+\n+\t\tforeach {posbegin colbegin posend colend} $markup {\n+\t\t\tset prefix clr\n+\t\t\tforeach style [split $colbegin \";\"] {\n+\t\t\t\tif {$style eq \"7\"} {append prefix i; continue}\n+\t\t\t\tif {$style < 30 || $style > 47} {continue}\n+\t\t\t\tset a \"$mark linestart + $posbegin chars\"\n+\t\t\t\tset b \"$mark linestart + $posend chars\"\n+\t\t\t\tcatch {.pane.out.grep tag add $prefix$style $a $b}\n+\t\t\t}\n+\t\t}\n+\t}\n+\n+\tforeach i $outcols {$i conf -state disabled}\n+\n+\tif {[eof $fd]} {\n+\t\tclose $fd\n+\t\tset current_grep_path $path\n+\t\twm title . \"git gui-grep: [escape_path $path]\"\n+\t}\n+}\n+\n+proc select_to_grep {x y} {\n+\tglobal grep_file_list current_grep_path\n+\n+\tset lno [lindex [split [.pane.files.list index @$x,$y] .] 0]\n+\tset path [lindex $grep_file_list [expr {$lno - 1}]]\n+\tif {$path eq {}} {\n+\t\treturn\n+\t}\n+\tif {$path eq $current_grep_path} {\n+\t\treturn\n+\t}\n+\tgrep_file $path\n+}\n+\n+proc open_in_git_editor {path {lno 0}} {\n+\tglobal env\n+\n+\tset env(FILENAME) $path\n+\tif {$lno != 0} {\n+\t\tset env(LINENUMBER) $lno\n+\t}\n+\texec [exec -- git var GIT_EDITOR] &\n+\tunset env(FILENAME)\n+\tcatch { unset env(LINENUMBER) }\n+}\n+\n+proc open_from_grep_view {w x y} {\n+\tglobal current_grep_path\n+\tglobal grep_file_list\n+\n+\tif {$current_grep_path eq {}} {\n+\t\treturn\n+\t}\n+\n+\tset grep_lno [lindex [split [$w index @$x,$y] .] 0]\n+\tset lno [.pane.out.lnos get $grep_lno.0 $grep_lno.end]\n+\tif {$lno eq {--}} {\n+\t\tincr grep_lno\n+\t\tset lno [.pane.out.lnos get $grep_lno.0 $grep_lno.end]\n+\t}\n+\n+\topen_in_git_editor $current_grep_path $lno\n+}\n+\n+\n+set grep_file_list [list]\n+set current_grep_path {}\n+set grep_patterns $argv\n+scan_grep\n-- \ntg: (6f10c41..) bw/git-gui/grep-support-prototype (depends on: master)\n"},{"id":"155888","messageId":"20101114215442.GC16413@burratino","threadId":"25747","inReplyTo":"1289770869-11665-1-git-send-email-bert.wesarg@googlemail.com","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-14T21:54:42Z","receivedAt":"2010-11-14T21:54:42Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Bert Wesarg wrote:\n\n> There is one feature that the upstream git gui lacks[1]: This grep gui can start\n> the git editor on every line by clicking with button 2 in the result area. The\n> git editor will than be started with the environment variable FILENAME and\n> LINENUMBER set but no argument given. This makes it possible to distinguish\n> between normal, blocking edit operation (like git commit) from this\n> open-and-forget type of operation.\n\nThis sounds like an excellent sort of thing to add to git grep -O, too\n(which currently has very limited support for editors' line number\nfeatures). But what will it do with typical non-git-specific setups\nlike\n\n\tVISUAL=vim\n\nor\n\n\tEDITOR=\"gvim --nofork\"\n\n?\n\nDo existing editors support LINENUMBER in the environment?\n"},{"id":"155889","messageId":"AANLkTiktg4aZ7VfdXUT9XF4RK7MuCvzevB5jSRaNiE1L@mail.gmail.com","threadId":"25747","inReplyTo":"20101114215442.GC16413@burratino","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-11-14T22:04:04Z","receivedAt":"2010-11-14T22:04:04Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Sun, Nov 14, 2010 at 22:54, Jonathan Nieder wrote:\n> Bert Wesarg wrote:\n>\n>> There is one feature that the upstream git gui lacks[1]: This grep gui can start\n>> the git editor on every line by clicking with button 2 in the result area. The\n>> git editor will than be started with the environment variable FILENAME and\n>> LINENUMBER set but no argument given. This makes it possible to distinguish\n>> between normal, blocking edit operation (like git commit) from this\n>> open-and-forget type of operation.\n>\n> This sounds like an excellent sort of thing to add to git grep -O, too\n> (which currently has very limited support for editors' line number\n> features).  But what will it do with typical non-git-specific setups\n> like\n>\n>        VISUAL=vim\n>\n> or\n>\n>        EDITOR=\"gvim --nofork\"\n>\n> ?\n>\n> Do existing editors support LINENUMBER in the environment?\n\nI don't expect this, I have a wrapper script around my editor to scan\nthe environment for these variables and pass the block/non-block\noption to the editor.\n\nBert\n"},{"id":"155891","messageId":"20101114220932.GE16413@burratino","threadId":"25747","inReplyTo":"AANLkTiktg4aZ7VfdXUT9XF4RK7MuCvzevB5jSRaNiE1L@mail.gmail.com","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-14T22:09:32Z","receivedAt":"2010-11-14T22:09:32Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Bert Wesarg wrote:\n> On Sun, Nov 14, 2010 at 22:54, Jonathan Nieder wrote:\n\n>> This sounds like an excellent sort of thing to add to git grep -O, too\n>> (which currently has very limited support for editors' line number\n>> features).  But what will it do with typical non-git-specific setups\n>> like\n>>\n>>        VISUAL=vim\n>>\n>> or\n>>\n>>        EDITOR=\"gvim --nofork\"\n>>\n>> ?\n>>\n>> Do existing editors support LINENUMBER in the environment?\n>\n> I don't expect this, I have a wrapper script around my editor to scan\n> the environment for these variables and pass the block/non-block\n> option to the editor.\n\nIn that case, perhaps something like\n\n\tGIT_EDITOR=$(git var GIT_EDITOR)\n\tset -- --open-file-named-in-the-environment\n\teval \"$GIT_EDITOR\" '\"$@\"' \n\nwould be appropriate? This way, existing editors like vi, ed, and\nemacs fail:\n\n\t$ ed --fjdkaslfjdas\n\ted: unrecognized option `--fjdkaslfjdas'\n\nrather than opening a new, empty file.\n"},{"id":"155892","messageId":"AANLkTi=JR3vVnZ4Yz8o9MpZKiQ2_ASYxahbPNv8QACir@mail.gmail.com","threadId":"25747","inReplyTo":"20101114220932.GE16413@burratino","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-11-14T22:15:12Z","receivedAt":"2010-11-14T22:15:12Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Sun, Nov 14, 2010 at 23:09, Jonathan Nieder wrote:\n> Bert Wesarg wrote:\n>> On Sun, Nov 14, 2010 at 22:54, Jonathan Nieder wrote:\n>\n>>> This sounds like an excellent sort of thing to add to git grep -O, too\n>>> (which currently has very limited support for editors' line number\n>>> features).  But what will it do with typical non-git-specific setups\n>>> like\n>>>\n>>>        VISUAL=vim\n>>>\n>>> or\n>>>\n>>>        EDITOR=\"gvim --nofork\"\n>>>\n>>> ?\n>>>\n>>> Do existing editors support LINENUMBER in the environment?\n>>\n>> I don't expect this, I have a wrapper script around my editor to scan\n>> the environment for these variables and pass the block/non-block\n>> option to the editor.\n>\n> In that case, perhaps something like\n>\n>        GIT_EDITOR=$(git var GIT_EDITOR)\n>        set -- --open-file-named-in-the-environment\n>        eval \"$GIT_EDITOR\" '\"$@\"'\n>\n> would be appropriate?  This way, existing editors like vi, ed, and\n> emacs fail:\n>\n>        $ ed --fjdkaslfjdas\n>        ed: unrecognized option `--fjdkaslfjdas'\n>\n> rather than opening a new, empty file.\n>\n\nNow I got your point. Maybe I should call GIT_EDITOR with $FILENAME as\nargument but with a new variable to indicate open'n'forget. So\nexisting setups would always open the file (even without honoring the\nline number) and new/smart wrappers can honor the open'n'forget and\nline number flag.\n\nBert\n"},{"id":"155897","messageId":"20101114234848.GB26104@burratino","threadId":"25747","inReplyTo":"AANLkTi=JR3vVnZ4Yz8o9MpZKiQ2_ASYxahbPNv8QACir@mail.gmail.com","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-14T23:48:48Z","receivedAt":"2010-11-14T23:48:48Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Bert Wesarg wrote:\n\n> Now I got your point. Maybe I should call GIT_EDITOR with $FILENAME as\n> argument but with a new variable to indicate open'n'forget. So\n> existing setups would always open the file (even without honoring the\n> line number) and new/smart wrappers can honor the open'n'forget and\n> line number flag.\n\nYes, I like the communication-via-environment idea.\n\nIn fact, there are multiple questions an editor might want answered:\n\n1. GUI or no GUI? (The combination of $DISPLAY and $(tty) often\n yields a reasonable answer.)\n\n2. open'n'forget or wait for answer? (gvim's --nofork option)\n\n3. What line number?\n\n4. regex to use to highlight matches?\n\nIdeally $LINENUMBER would only be used represent (3), while a\nseparate variable would indicate (2).\n"},{"id":"156171","messageId":"AANLkTimWyjrRD951AGeEayMoTNd-N2OXRd_wQ0RBFegN@mail.gmail.com","threadId":"25747","inReplyTo":"20101114234848.GB26104@burratino","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-11-19T12:15:44Z","receivedAt":"2010-11-19T12:15:44Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Mon, Nov 15, 2010 at 00:48, Jonathan Nieder wrote:\n> Bert Wesarg wrote:\n>\n>> Now I got your point. Maybe I should call GIT_EDITOR with $FILENAME as\n>> argument but with a new variable to indicate open'n'forget. So\n>> existing setups would always open the file (even without honoring the\n>> line number) and new/smart wrappers can honor the open'n'forget and\n>> line number flag.\n>\n> Yes, I like the communication-via-environment idea.\n>\n> In fact, there are multiple questions an editor might want answered:\n>\n> 1. GUI or no GUI?  (The combination of $DISPLAY and $(tty) often\n>   yields a reasonable answer.)\n\nI think we can generalize this by using the name of the caller (ie\nbinary name). This is easy to get in a unix/linux shell with the help\nof /proc/$PPID/exe, but maybe not so in others OS's. I just remembered\nthat quilt has this feature, the name is QUILT_COMMAND and I use is in\nmy wrapper script to detect whether the caller wants to wait or not (I\nblock only on the header and mail command).\n\n>\n> 2. open'n'forget or wait for answer?  (gvim's --nofork option)\n>\n> 3. What line number?\n>\n> 4. regex to use to highlight matches?\n>\n> Ideally $LINENUMBER would only be used represent (3), while a\n> separate variable would indicate (2).\n>\n\nUsing for each case its own flag may sound silly, but I think this\nmakes it more clear, what the caller expects.\nFor example in my git-patch for calling GIT_EDITOR I provide a flag\nwhether the given path is in the index or not (ie the action comes\nfrom the index list). If it is from the index, I use checkout-index\n--temp and update-index to edit the content from the index. This call\nto GIT_EDITOR should be blocking but it is better to request this\nexplicitly.\n\nCould we settle on a name space for such variables? GIT_EDITOR_* makes\nit obvious that it is for the editor started from git.\n\nBert\n"},{"id":"156204","messageId":"20101119194907.GG26187@burratino","threadId":"25747","inReplyTo":"AANLkTimWyjrRD951AGeEayMoTNd-N2OXRd_wQ0RBFegN@mail.gmail.com","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-11-19T19:49:07Z","receivedAt":"2010-11-19T19:49:07Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"[resending to list; sorry for the noise]\n\nBert Wesarg wrote:\n\n> Could we settle on a name space for such variables? GIT_EDITOR_* makes\n> it obvious that it is for the editor started from git.\n\nSounds good to me.\n\nIf the choice of variables ends up looking especially good, maybe\nwe can pass it along to the Portland group and call it xdg-editor for\nuse by other apps, too. :)\n"},{"id":"156205","messageId":"AANLkTi=-OGvTT+yVqQWUyGn0PmODr=dv1DE9fZkaEDBB@mail.gmail.com","threadId":"25747","inReplyTo":"20101119194907.GG26187@burratino","subject":"Re: [PATCH/RFC/WIP/POC] git-gui: grep prototype","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2010-11-19T20:16:21Z","receivedAt":"2010-11-19T20:16:21Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Fri, Nov 19, 2010 at 20:49, Jonathan Nieder wrote:\n> [resending to list; sorry for the noise]\n\nNo problem.\n\n>\n> Bert Wesarg wrote:\n>\n>> Could we settle on a name space for such variables? GIT_EDITOR_* makes\n>> it obvious that it is for the editor started from git.\n>\n> Sounds good to me.\n>\n> If the choice of variables ends up looking especially good, maybe\n> we can pass it along to the Portland group and call it xdg-editor for\n> use by other apps, too. :)\n>\n\nInteresting idea.\n\nThere is one more thing to discuss before starting collecting the\nvariables. Has each flag its own env-variable, or do we put flags into\none variable named GIT_EDITOR_FLAGS? They could be space or comma\nseparated.\n\nThe second option sounds a little bit more future prove to me.\n\nFor non-flag arguments, there is the obvious LINENUMBER. But how do we\npass columns or even a character range to the editor. They would be\ngood for compiler output. Sure its out of score for git, but a little\nfuture-thinking will not hurt. We could add it to the LINENUMBER with\na syntax like:\n\n [:]]\n\nBert\n"}]}