Look for git info in background

Look for git info in background

[Teto]

Hi,

I display "git" informations in my prompt such as branch name, number
of commits since last push etc... but on big repositories, it takes
some time to retrieve.

I would like to display the prompt as soon as I know if the folder is
a git repo or not so that I can enter commands in the prompt. I would
like zsh to retrieve that info (number of commtis ahead of upstream
etc...) in background and update my prompt when the information
becomes available.

has anyone some code for that, I couldn't find anything ?

Regards
Matt

Trouble with 'fc -l'

[Ray Andrews]

All,

If I run " fc -l -1 " from the command line, it works as expected, however:


function z ()
{
   fc -R
   fc -l -1
}

When 'z' is executed, my entire saved history scrolls past and history 
itself is 'advanced' by several thousand places.  I can have either 
line:  " fc -R " or " fc -l -1 "  alone in the function and it works as 
expected.  I can also do this:

function z ()
{
   fc -R
   fc -l
}

... and it works fine--I get the last 16 lines of updated history as I 
should.  But whenever I try to modify " fc -l ... " in any way, I get 
either a "no such event: 0" message, or ,again, the whole of history 
scrolls by.  It seems very strange, what am I doing wrong?

Re: Look for git info in background

[Bart Schaefer]

On Feb 17,  1:05am, Teto wrote:
}
} I would like to display the prompt as soon as I know if the folder is
} a git repo or not so that I can enter commands in the prompt. I would
} like zsh to retrieve that info (number of commtis ahead of upstream
} etc...) in background and update my prompt when the information
} becomes available.
} 
} has anyone some code for that, I couldn't find anything ?

Hmm.  Something like this:

  autoload -Uz vcs_info

  vcs_update_info () {
    eval $(read -rE -u$1)		# Receive and run typeset
    zle -F $1				# Remove the handler
    exec {1}>&-				# Close the descriptor
    zle reset-prompt
  }
  zle -N vcs_update_info

  chpwd() {
    if zle -l vcs_update_info
    then
      typeset -g vcs_info_msg_0_= vcs_info_fd=
    fi
  }

  precmd() {
    if zle -l vcs_update_info
    then
      # NO_monitor / disown is to silence background job notices
      setopt localoptions NO_monitor
      coproc {
        sleep 1				# Assure disown runs first
        vcs_info			# Populate vcs_info_msg_0_
        typeset -p vcs_info_msg_0_	# Send typeset to parent
      }
      disown %${(k)^jobtexts[(R)*vcs_info*]}
      exec {vcs_info_fd}<&p		# Get descriptor for handler
      zle -F -w $vcs_info_fd vcs_update_info
    fi
  }

Then set up your prompts to include $vcs_info_msg_0_ as you normally
would.

Aside to zsh-workers:  It's generally a good thing that the coproc
mechanism now uses the job tables, etc., but it would be nice if it
could be made to shut up about the jobs starting/finishing without
having to disable the monitor and notify options entirely.

Re: Trouble with 'fc -l'

[Bart Schaefer]

On Feb 16,  5:41pm, Ray Andrews wrote:
}
} function z ()
} {
}    fc -R
}    fc -l -1
} }
} 
} When 'z' is executed, my entire saved history scrolls past and history 
} itself is 'advanced' by several thousand places.

This is subtle, and the documentation is could be clearer.

     Select a range of commands from FIRST to LAST from the history
     list.  The arguments FIRST and LAST may be specified as a number
     or as a string.  A negative number is used as an offset to the
     current history event number.  A string specifies the most recent
     event beginning with the given string.

     If FIRST is not specified, it will be set to -1 (the most recent
     event), or to -16 if the -l flag is given.  If LAST is not
     specified, it will be set to FIRST, or to -1 if the -l flag is
     given.

Note "offset to the current history event number".

Let's say you're on history event number 127, and you have SAVEHIST=100,
and you've been running the shell long enough that there actually are
100 saved commands in $HISTFILE.  This means you actually have 126
events in the shell history and are about to execute number 127.  You
now execute your "z" function.

"fc -R" re-reads 100 events from $HISTFILE and appends then to the
current history.  This increments the largest event number to 227, but
it DOES NOT change the "current history event number" of the command
that you just ran!  Your HISTSIZE now kicks in.  If it's larger than
227, nothing happens.  If it is smaller, say 200, then the oldest 27
events are discarded and you now have 200 events numbered 28 through
227, and you are currently on event 127 ("z").  "fc -R" is done.

Now "fc -l -1" kicks in and applies the "offset to current event" rule,
coming up with a FIRST event of 126.  (If you do not give -1, then it
is offset -16 from the "most recent" history number, and you get 212.)
Next LAST has to be computed, and this is where things get strange:
if you did NOT specify a number for LAST (as is the case here) AND the
"current event" is NOT the "most recent event", then LAST is computed
relative to the "most recent event" instead of the "current event",
and you get a range of 126 through 227.  These 102 events are then
printed and "fc -l" is done.

This oddity with LAST is done so that if you explicitly shove events
onto the the history with "print -s" or the like, "history" ("fc -l")
will show you what you added.  "fc -R" happens to be a (very large)
case of the same thing.  If it behaved exactly the way the doc reads,
you'd see only event 126 (or get "no such event" because HISTSIZE
lopped that event off the front) and be puzzled about why it doesn't
show you the newly-added events.

} But whenever I try to modify " fc -l ... " in any way, I get 
} either a "no such event: 0" message, or ,again, the whole of history 
} scrolls by.

The "no such event" message probably occurs when HISTSIZE has caused
enough events to be thrown away that both FIRST and LAST are before
the earliest remaining history number.  This would only occur if you
actually provided a value for LAST, because in that case it goes back
to counting from "current event" instead of "most recent" (and that
whole history you just loaded with "fc -R" becomes invisible).

So how exactly does one display the most recent event from a newly-
reloaded history?  That's where the HISTCMD parameter comes in:

    z() {
      fc -R
      fc -l $HISTCMD
    }

Unlike the "current event", the value of HISTCMD is incremented when
the new history is read.  (Hmm, seems the doc for HISTCMD is also
incomplete.)  Note that before "fc -R", $HISTCMD refers to the event
number assigned to the current command (as its doc says), but after
"fc -R" (or "print -s") it refers to the last event that was loaded
(and the "most recent event" is $[HISTCMD+1] even though that hasn't
happened yet).

Re: Trouble with 'fc -l'

[Ray Andrews]

On 02/17/2014 12:29 AM, Bart Schaefer wrote:
> On Feb 16,  5:41pm, Ray Andrews wrote:
> }
> } function z ()
> } {
> }    fc -R
> }    fc -l -1
> } }
> }
> } When 'z' is executed, my entire saved history scrolls past and history
> } itself is 'advanced' by several thousand places.
>
> This is subtle, and the documentation is could be clearer.

Never! ;-)
> ...

> So how exactly does one display the most recent event from a newly-
> reloaded history?  That's where the HISTCMD parameter comes in:

> z() {
>        fc -R
>        fc -l $HISTCMD
>      }
>
>
Well I dunno Bart, my mind is big enough for Kant, but not big enough 
for all this stuff.  I'm glad you understand  it.  All I can add it 
that  " fc -l $HISTCMD " WORKS!  The byzantine complexities I leave to 
better men.  Thanks again.  But does it really need to be so obscure? I 
suppose so.

Re: Trouble with 'fc -l'

[Bart Schaefer]

On Feb 17,  7:37am, Ray Andrews wrote:
}
} The byzantine complexities I leave to better men. Thanks again. But
} does it really need to be so obscure? I suppose so.

Zsh was originally intended to "just do the right thing" for college
students who had never encountered a shell before.

Then those college students got a bit more familiar with UNIX and
shells and wanted zsh to do "do things that make interacting with it
daily, faster and more intelligent" and so thing started getting
added in which didn't always play nicley with stuff that was there
already.

And then a whole lot of other people started using zsh too, and they
wanted to customize the "faster and more intelligent" part for their
personal environment and preferences, and a whole lot of controls got
added for changing the ways all those previously-added things work.

And now when you look in the dictionary under "exponential complexity"
you get referred to the zsh documentation.

Re: Trouble with 'fc -l'

[Ray Andrews]

On 02/17/2014 08:18 AM, Bart Schaefer wrote:
> On Feb 17,  7:37am, Ray Andrews wrote:
> }
> } The byzantine complexities I leave to better men. Thanks again. But
> } does it really need to be so obscure? I suppose so.
>
> ....

> And now when you look in the dictionary under "exponential complexity"
> you get referred to the zsh documentation.
>
Well said.  I fear the day comes when no one knows how it works anymore, 
yet deconstructing some of these layers could prove to be a super human 
challenge.  One sees why folks want to start again with a clean sheet of 
paper.

Re: Look for git info in background

[Nick Cross]

Hi,

Apologies for resurrecting such an old thread ;-) However, on the same 
topic rather than using vcs_info is it also possible to run a python 
script in the background to update the prompt e.g.

https://github.com/olivierverdier/zsh-git-prompt/blob/master/zshrc.sh#L42

where PROMPT might be

PROMPT='%m$(git_super_status) $ '

It wasn't quite clear to me (sorry :-( ) how one might/could use coproc 
in this scenario.

Thanks

Nick


On 17/02/14 02:20, Bart Schaefer wrote:
> On Feb 17,  1:05am, Teto wrote:
> }
> } I would like to display the prompt as soon as I know if the folder is
> } a git repo or not so that I can enter commands in the prompt. I would
> } like zsh to retrieve that info (number of commtis ahead of upstream
> } etc...) in background and update my prompt when the information
> } becomes available.
> }
> } has anyone some code for that, I couldn't find anything ?
>
> Hmm.  Something like this:
>
>    autoload -Uz vcs_info
>
>    vcs_update_info () {
>      eval $(read -rE -u$1)		# Receive and run typeset
>      zle -F $1				# Remove the handler
>      exec {1}>&-				# Close the descriptor
>      zle reset-prompt
>    }
>    zle -N vcs_update_info
>
>    chpwd() {
>      if zle -l vcs_update_info
>      then
>        typeset -g vcs_info_msg_0_= vcs_info_fd=
>      fi
>    }
>
>    precmd() {
>      if zle -l vcs_update_info
>      then
>        # NO_monitor / disown is to silence background job notices
>        setopt localoptions NO_monitor
>        coproc {
>          sleep 1				# Assure disown runs first
>          vcs_info			# Populate vcs_info_msg_0_
>          typeset -p vcs_info_msg_0_	# Send typeset to parent
>        }
>        disown %${(k)^jobtexts[(R)*vcs_info*]}
>        exec {vcs_info_fd}<&p		# Get descriptor for handler
>        zle -F -w $vcs_info_fd vcs_update_info
>      fi
>    }
>
> Then set up your prompts to include $vcs_info_msg_0_ as you normally
> would.
>
> Aside to zsh-workers:  It's generally a good thing that the coproc
> mechanism now uses the job tables, etc., but it would be nice if it
> could be made to shut up about the jobs starting/finishing without
> having to disable the monitor and notify options entirely.
>

Re: Look for git info in background

[Bart Schaefer]

On Apr 8, 11:36am, Nick Cross wrote:
}
} Apologies for resurrecting such an old thread ;-) However, on the same 
} topic rather than using vcs_info is it also possible to run a python 
} script in the background to update the prompt e.g.
} 
} PROMPT='%m$(git_super_status) $ '

The basic pattern is:

(1) precmd (or entry in precmd_functions) that creates a background
    job writing to a file descriptor

(2) widget that reads from that descriptor and updates the prompt

(3) chpwd (or chpwd_functions) that clears the old info so the prompt
    won't be misleading before the widget updates it

If the state can change rapidly at times other than change of directory,
drop the third step and clear the old info in the precmd.

Something I didn't deal with in the vcs_info example was the possibility
of a race, e.g., if new prompts appear faster than the background jobs
finish then you may have multiple of them waiting to update the prompt
and they may do so in the wrong order.  The precmd ought to remove the
old handler before creating the new one.

The vcs_info example is also a little special because it communicates
through the vcs_info_msg_0_ parameter instead of text output, so to
background it required generating a typeset command to pass the value
up to the parent, which then eval'd the typeset.  That's not needed
in a case like $(git_super_status) where the output is directly used.

I don't recall now why I decided to use a coproc for the background job
instead of <<(...) substitution, which is easier.

  typeset -g update_prompt_fd
  PROMPT='%m[waiting] $ '

  update_super_status () {
    PROMPT="%m$(read -rE -u$1) $ "  # double quotes, not promptsubst
    update_prompt_fd=0
    zle -F $1
    exec {1}>&-
    zle reset-prompt
  }
  zle -N update_super_status  

  chpwd () {
    if zle -l update_super_status
    then
      PROMPT='%m[waiting] $ '
    fi
  }

  precmd () {
    if zle -l update_super_status
    then
      (( update_prompt_fd )) && zle -F $update_prompt_fd >/dev/null
      exec {update_prompt_fd}<<( git_super_status )
      zle -F -w $update_prompt_fd update_super_status
    fi
  }

Re: Look for git info in background

[Nick Cross]

Hi,

Thanks for the reply. Bizarrely I am getting

precmd_update_git_vars:6: bad option: -w

from

zle -F -w

Using rpm -q zsh
zsh-5.0.2-5.fc19.x86_64

Regards

Nick

On 08/04/14 16:25, Bart Schaefer wrote:
> On Apr 8, 11:36am, Nick Cross wrote:
> }
> } Apologies for resurrecting such an old thread ;-) However, on the same
> } topic rather than using vcs_info is it also possible to run a python
> } script in the background to update the prompt e.g.
> }
> } PROMPT='%m$(git_super_status) $ '
>
> The basic pattern is:
>
> (1) precmd (or entry in precmd_functions) that creates a background
>      job writing to a file descriptor
>
> (2) widget that reads from that descriptor and updates the prompt
>
> (3) chpwd (or chpwd_functions) that clears the old info so the prompt
>      won't be misleading before the widget updates it
>
> If the state can change rapidly at times other than change of directory,
> drop the third step and clear the old info in the precmd.
>
> Something I didn't deal with in the vcs_info example was the possibility
> of a race, e.g., if new prompts appear faster than the background jobs
> finish then you may have multiple of them waiting to update the prompt
> and they may do so in the wrong order.  The precmd ought to remove the
> old handler before creating the new one.
>
> The vcs_info example is also a little special because it communicates
> through the vcs_info_msg_0_ parameter instead of text output, so to
> background it required generating a typeset command to pass the value
> up to the parent, which then eval'd the typeset.  That's not needed
> in a case like $(git_super_status) where the output is directly used.
>
> I don't recall now why I decided to use a coproc for the background job
> instead of <<(...) substitution, which is easier.
>
>    typeset -g update_prompt_fd
>    PROMPT='%m[waiting] $ '
>
>    update_super_status () {
>      PROMPT="%m$(read -rE -u$1) $ "  # double quotes, not promptsubst
>      update_prompt_fd=0
>      zle -F $1
>      exec {1}>&-
>      zle reset-prompt
>    }
>    zle -N update_super_status
>
>    chpwd () {
>      if zle -l update_super_status
>      then
>        PROMPT='%m[waiting] $ '
>      fi
>    }
>
>    precmd () {
>      if zle -l update_super_status
>      then
>        (( update_prompt_fd )) && zle -F $update_prompt_fd >/dev/null
>        exec {update_prompt_fd}<<( git_super_status )
>        zle -F -w $update_prompt_fd update_super_status
>      fi
>    }
>

Re: Look for git info in background

[Bart Schaefer]

On Apr 8,  5:01pm, Nick Cross wrote:
}
} precmd_update_git_vars:6: bad option: -w
} 
} zsh-5.0.2-5.fc19.x86_64

Oh.  The -w option was added in 5.0.3.  Prior to that you'll have to use a
plain function for the zle -F handler and probably a TRAPUSR1 or the like,
replacing "zle reset-prompt" with "kill -USR1 $$" ... I don't have time
just now to work out the details.

Re: Look for git info in background

[Nick Cross]

After compiling up a 5.0.5 (and commenting out most of my .zshrc as some 
option was causing a "can't clobber parameter" file descriptor issue) I 
finally got it working - very neat!

Thanks

Nick


On 08/04/14 16:25, Bart Schaefer wrote:
> On Apr 8, 11:36am, Nick Cross wrote:
> }
> } Apologies for resurrecting such an old thread ;-) However, on the same
> } topic rather than using vcs_info is it also possible to run a python
> } script in the background to update the prompt e.g.
> }
> } PROMPT='%m$(git_super_status) $ '
>
> The basic pattern is:
>
> (1) precmd (or entry in precmd_functions) that creates a background
>      job writing to a file descriptor
>
> (2) widget that reads from that descriptor and updates the prompt
>
> (3) chpwd (or chpwd_functions) that clears the old info so the prompt
>      won't be misleading before the widget updates it
>
> If the state can change rapidly at times other than change of directory,
> drop the third step and clear the old info in the precmd.
>
> Something I didn't deal with in the vcs_info example was the possibility
> of a race, e.g., if new prompts appear faster than the background jobs
> finish then you may have multiple of them waiting to update the prompt
> and they may do so in the wrong order.  The precmd ought to remove the
> old handler before creating the new one.
>
> The vcs_info example is also a little special because it communicates
> through the vcs_info_msg_0_ parameter instead of text output, so to
> background it required generating a typeset command to pass the value
> up to the parent, which then eval'd the typeset.  That's not needed
> in a case like $(git_super_status) where the output is directly used.
>
> I don't recall now why I decided to use a coproc for the background job
> instead of <<(...) substitution, which is easier.
>
>    typeset -g update_prompt_fd
>    PROMPT='%m[waiting] $ '
>
>    update_super_status () {
>      PROMPT="%m$(read -rE -u$1) $ "  # double quotes, not promptsubst
>      update_prompt_fd=0
>      zle -F $1
>      exec {1}>&-
>      zle reset-prompt
>    }
>    zle -N update_super_status
>
>    chpwd () {
>      if zle -l update_super_status
>      then
>        PROMPT='%m[waiting] $ '
>      fi
>    }
>
>    precmd () {
>      if zle -l update_super_status
>      then
>        (( update_prompt_fd )) && zle -F $update_prompt_fd >/dev/null
>        exec {update_prompt_fd}<<( git_super_status )
>        zle -F -w $update_prompt_fd update_super_status
>      fi
>    }
>

Re: Look for git info in background

[Bart Schaefer]

On Apr 9,  9:26am, Nick Cross wrote:
}
} After compiling up a 5.0.5 (and commenting out most of my .zshrc as some 
} option was causing a "can't clobber parameter" file descriptor issue) I 
} finally got it working - very neat!

Ah, that would be the NO_CLOBBER option, and must be coming from

      exec {update_prompt_fd}<<( git_super_status )

I'm a little surprised you ran into that because it means (I think) that
precmd is in fact running more than once before the update_super_status
handler has been called.  If you change the line

      (( update_prompt_fd )) && zle -F $update_prompt_fd >/dev/null

to instead

      if (( update_prompt_fd ))
      then
         zle -F $update_prompt_fd >/dev/null && exec {update_promp_fd}<&-
      fi

then you should be able to have NO_CLOBBER set again.

Re: Look for git info in background

[Nick Cross]

Hi,

Now that ZSH 5.0.5 has (finally) arrived in the Fedora repositories I 
dug up this old thread once more.

One quirk I have noticed with your suggested code (thanks *very* much 
Bart) is that Ctrl-C on a blank line does not appear to work ... in fact 
it seems to get 'cached' ; I can hit Ctrl-C, nothing happens (I might 
expect it to give me a new terminal line), then press a key and the 
ctrl-c happens. It works fine on a line with random content/processes.

Any suggestions please :-)

Thanks

Nick


On 08/04/14 16:25, Bart Schaefer wrote:
> On Apr 8, 11:36am, Nick Cross wrote:
> }
> } Apologies for resurrecting such an old thread ;-) However, on the same
> } topic rather than using vcs_info is it also possible to run a python
> } script in the background to update the prompt e.g.
> }
> } PROMPT='%m$(git_super_status) $ '
>
> The basic pattern is:
>
> (1) precmd (or entry in precmd_functions) that creates a background
>      job writing to a file descriptor
>
> (2) widget that reads from that descriptor and updates the prompt
>
> (3) chpwd (or chpwd_functions) that clears the old info so the prompt
>      won't be misleading before the widget updates it
>
> If the state can change rapidly at times other than change of directory,
> drop the third step and clear the old info in the precmd.
>
> Something I didn't deal with in the vcs_info example was the possibility
> of a race, e.g., if new prompts appear faster than the background jobs
> finish then you may have multiple of them waiting to update the prompt
> and they may do so in the wrong order.  The precmd ought to remove the
> old handler before creating the new one.
>
> The vcs_info example is also a little special because it communicates
> through the vcs_info_msg_0_ parameter instead of text output, so to
> background it required generating a typeset command to pass the value
> up to the parent, which then eval'd the typeset.  That's not needed
> in a case like $(git_super_status) where the output is directly used.
>
> I don't recall now why I decided to use a coproc for the background job
> instead of <<(...) substitution, which is easier.
>
>    typeset -g update_prompt_fd
>    PROMPT='%m[waiting] $ '
>
>    update_super_status () {
>      PROMPT="%m$(read -rE -u$1) $ "  # double quotes, not promptsubst
>      update_prompt_fd=0
>      zle -F $1
>      exec {1}>&-
>      zle reset-prompt
>    }
>    zle -N update_super_status
>
>    chpwd () {
>      if zle -l update_super_status
>      then
>        PROMPT='%m[waiting] $ '
>      fi
>    }
>
>    precmd () {
>      if zle -l update_super_status
>      then
>        (( update_prompt_fd )) && zle -F $update_prompt_fd >/dev/null
>        exec {update_prompt_fd}<<( git_super_status )
>        zle -F -w $update_prompt_fd update_super_status
>      fi
>    }
>