You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The recording strategy (for text files) works on a per-command basis, i.e. record a frame when a command is executed. This can generate inconsistencies when dealing with external programs that can have variant response times, thus affecting golden file stability. Right now, the only way to avoid this is by doing a Hide/Run the program and wait a while for it to return/Show dance that can make the tape file a bit annoying to navigate.
Describe the solution you'd like
It would be great to have a command Set CaptureMode which could either be OnCommand (the default one) or OnDemand. Setting the capture mode to OnDemand would disable the tool from recording an output at every command and only record the output when executing a specific command (e.g. Capture).
Describe alternatives you've considered
This could also be achieved by adding a configuration flag to the binary, such as -capturemode=. It's up to you guys to decide which one would be the best approach.
Additional context
Here's a simple use case with a variant response time executable:
// Quits after finding a multiple of 10 or after 1 second.funcmain() {
found:=make(chanstruct{})
gofunc() {
for {
ifrand.Int()%10!=0 {
time.Sleep(200*time.Millisecond)
continue
}
close(found)
break
}
}()
select {
case<-found:
fmt.Println("Found :)")
case<-time.After(time.Second):
fmt.Println("Timed out :(")
}
}
Running the above with a simple tape file:
Output simple.txt
Type "./stopWhenFound"
Enter
Sleep 1s
We can have this (when the number is found immediately):
> ./stopWhenFound
────────────────────────────────────────────────────────────────────────────────
> ./stopWhenFound
Found :)
>
────────────────────────────────────────────────────────────────────────────────
> ./stopWhenFound
Found :)
>
────────────────────────────────────────────────────────────────────────────────
Output hiding.txt
Hide
Type "./stopWhenFound"
Enter
Sleep 1s
Show
# The final sleep necessary when using hide/sleep, as vhs must have a .gif output and
# will fail with a "no frames" error if it can't generate it, even though the above should be
# enough for the text output.
# This can be avoided if https://github.com/charmbracelet/vhs/issues/363 gets addressed.
Sleep 100ms
We can have a single frame with the output (the last frame is due to the "required" sleep in the end):
> ./stopWhenFound
Found :)
>
────────────────────────────────────────────────────────────────────────────────
> ./stopWhenFound
Found :)
>
────────────────────────────────────────────────────────────────────────────────
On simple files, the hide/sleep isn't that bad, but when dealing with more complex interactions it can escalate fast. This could be avoided by the suggestion listed in this issue, since (instead of hiding/showing) we could use a Capture line that would record the current terminal frame.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The recording strategy (for text files) works on a per-command basis, i.e. record a frame when a command is executed. This can generate inconsistencies when dealing with external programs that can have variant response times, thus affecting golden file stability. Right now, the only way to avoid this is by doing a
Hide
/Run the program and wait a while for it to return/Show
dance that can make the tape file a bit annoying to navigate.Describe the solution you'd like
It would be great to have a command
Set CaptureMode
which could either beOnCommand
(the default one) orOnDemand
. Setting the capture mode toOnDemand
would disable the tool from recording an output at every command and only record the output when executing a specific command (e.g.Capture
).Describe alternatives you've considered
This could also be achieved by adding a configuration flag to the binary, such as
-capturemode=
. It's up to you guys to decide which one would be the best approach.Additional context
Here's a simple use case with a variant response time executable:
Running the above with a simple tape file:
We can have this (when the number is found immediately):
Or this (when the number is found after a while):
When using
Hide
/Sleep
:We can have a single frame with the output (the last frame is due to the "required" sleep in the end):
On simple files, the hide/sleep isn't that bad, but when dealing with more complex interactions it can escalate fast. This could be avoided by the suggestion listed in this issue, since (instead of hiding/showing) we could use a
Capture
line that would record the current terminal frame.The text was updated successfully, but these errors were encountered: