基于最近合并的 #156,我想提出以下功能: --max-wait
选项可以采用最大等待界限的序列(或者可能有另一个选项)。 例如:
asciinema rec -w 0.4 0.8 1 3
(格式是可以讨论的,可能带有非空格分隔符的东西更好/更容易解析: 0.4,0.8,1,3
)
这将意味着
max-wait
)这将允许对录音的时间流进行更多调整,例如最大限度地减少打字延迟(使其更加流畅),同时仍然能够进行短暂停顿和长暂停(指出某事)。
你觉得这个功能怎么样? 我认为这并不难,而且我可以实现它。
@sickill 对此有何意见?
这是一个有趣的想法。 我有一种感觉,这将被非常少的用户使用。 -w
现在已经非常有用了,但据我所知,使用它的人并不多——人们只是使用默认值。
我在这里犹豫不决......一方面我真的很喜欢这个想法,另一方面我知道它会增加相当数量的代码,需要为大约 1% 的用户维护的代码(证明我错了至于这里的估计;))
那这个呢:
我有一段时间有这个想法来创建一组单独的工具来处理 asciicasts。 诸如将其加速 2 倍之类的东西,将-w
算法应用于已录制的 asciicast 文件,定位+擦除任意文本(可见密码)。
我们可以有一种机制来向asciinema
添加额外的命令,方法与git
- 当您运行asciinema foo
它会检查foo
是否是它的内部命令,如果不是,它会在$PATH
查找asciinema-foo
二进制文件并运行它。 您可以用任何语言编写额外的命令。
有了以上,我们可以创建asciinema-quantize
,或者更通用的asciinema-process
,它可以支持各种开关(比如改进的-w
,也许-s
来改变速度全程录音)。 它将读取输入 json,根据选项处理它,并写入输出 json。 如果它是一个流行的命令,它可以被提升为内部命令(或作为asciinema-*
二进制文件在 asciinema 包中发送)。
我愿意接受其他建议!
其实我也是这么想的:在外部做,只是处理记录json文件。 另一件事是我现在没有太多时间来学习 Go,但是如果这种外部命令集成可以与约定命名的任何可执行文件一起使用,这可以使 asciinema 的扩展更容易。
顺便说一句,我猜您知道asciinema2gif ,它非常有用且有效。 我在这里看到了一些关于 gif 转换的讨论,但它不在计划中,我完全理解它,但由于用户可能有不同的需求,这种可扩展性可能是让用户自己满足其特定需求的一种非常好的方式。
很高兴听到类似的意见。 你更熟悉Python吗? 你会用什么语言来实现这个?
@sickill好吧,实际上到目前为止我一直在使用jq和一些原始过滤器。 例如:
jq '.stdout |= map(.[0] *= 0.5)' record.json > record.twice-faster.json
将生成一个 json,它会被asciinema play
快两倍播放。 或者
jq '.stdout |= map(.[0] |= ([., 1.234] | min))' record.json > record.cut.json
与将max-wait
时间设置为1.234
。 我不是 jq-guru,所以可能它可以更容易地完成,但这很简单(如果大家熟悉 jq)并且它有效。 以这种方式实现所提出的时间量化功能有点复杂,但也很简单。
当然,这可以包含在具有指定选项的任何类型的 shell 脚本中。 但是,如果您想要更多的集成,也可以使用JMESPath以实现,包括 Python 和 Go。
嘿@laughedelic ,
我和你的要求几乎一样,所以我最终创建了这个https://github.com/cirocosta/asciinema-edit
它需要一个 asciinema cast (v2),然后根据您的需要改变事件流。
我刚刚按照你描述的方式添加了量化,顺便说一句👍
希望对你有用!
谢谢!
嗨@cirocosta! 谢谢你ping我! 你把它变成了一个工具并且它可以与 v2 格式一起工作,真是太棒了。 下次我录制 asciinema 演员表时,我会尝试一下。
最有用的评论
嘿@laughedelic ,
我和你的要求几乎一样,所以我最终创建了这个https://github.com/cirocosta/asciinema-edit
它需要一个 asciinema cast (v2),然后根据您的需要改变事件流。
我刚刚按照你描述的方式添加了量化,顺便说一句👍
希望对你有用!
谢谢!