Основываясь на недавно объединенном # 156, я хочу предложить следующую функцию: --max-wait
option может принимать последовательность максимальных границ ожидания (или для этого может быть другой вариант). Например:
asciinema rec -w 0.4 0.8 1 3
(формат обсуждается, возможно, что-то с разделителем, отличным от пробела, лучше / легче разобрать: 0.4,0.8,1,3
)
Это означало бы, что
max-wait
)Это позволило бы внести некоторые дополнительные коррективы во временной поток записи, например, минимизировать задержки набора текста (сделать его более плавным), сохраняя при этом возможность делать короткие и длинные паузы (чтобы что-то отметить).
Что вы думаете об этой функции? Думаю, сделать это несложно и я смог бы это реализовать.
@sickill есть
Это интересная идея. У меня есть ощущение, что это будет использовать очень небольшое количество пользователей. -w
в том виде, в каком он есть сегодня, уже очень полезен, но, насколько я знаю, не многие люди используют его - люди просто используют значения по умолчанию.
Я здесь на заборе ... С одной стороны, мне очень нравится эта идея, с другой - я знаю, что она добавит изрядное количество кода, кода, который нужно будет поддерживать, вероятно, для 1% пользователей (докажите, что я ошибаюсь насчет оценок тут;))
Как насчет этого:
Какое-то время у меня возникла идея создать отдельный набор инструментов для обработки асцикастов. Такие вещи, как ускорение в 2 раза, применение алгоритма -w
к уже записанному файлу asciicast, поиск + удаление произвольного текста (видимые пароли).
У нас может быть механизм для добавления дополнительных команд в asciinema
, выполняемый так же, как в git
- когда вы запускаете asciinema foo
он проверяет, является ли foo
его внутренняя команда, в противном случае она ищет двоичный файл asciinema-foo
в $PATH
и запускает его вместо этого. Вы можете писать дополнительные команды на любом языке.
Имея вышеуказанное, мы могли бы создать 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
time на 1.234
. Я не jq-гуру, так что, вероятно, это можно сделать проще, но это довольно просто (если кто-то знаком с jq в целом), и это работает. Реализация предлагаемой функции квантования времени таким способом немного сложнее, но также тривиальна.
Это, конечно, может быть заключено в любой сценарий оболочки с указанными параметрами. Но если вам нужна дополнительная интеграция, это также можно сделать _ очень похожим_ способом, используя JMESPath , который имеет различные реализации, включая Python и Go.
Привет @laughedelic ,
У меня были примерно те же требования, что и у вас, поэтому я создал этот https://github.com/cirocosta/asciinema-edit
Он принимает asciinema cast (v2), а затем мутирует поток событий в соответствии с тем, что вам нужно.
Я только что закончил добавлять квантование, как вы описали, кстати 👍
Надеюсь, это будет полезно для вас!
Спасибо!
Привет @cirocosta! Спасибо, что позвонили мне! Замечательно, что вы превратили его в инструмент и что он работает с форматом v2. Я попробую это сделать в следующий раз, когда запишу асинематографический состав.
Самый полезный комментарий
Привет @laughedelic ,
У меня были примерно те же требования, что и у вас, поэтому я создал этот https://github.com/cirocosta/asciinema-edit
Он принимает asciinema cast (v2), а затем мутирует поток событий в соответствии с тем, что вам нужно.
Я только что закончил добавлять квантование, как вы описали, кстати 👍
Надеюсь, это будет полезно для вас!
Спасибо!