Request: !Interactive - long strings

[Billiam]

I don't know what the format of this would be, but I think the keys array could be improved by also allowing a string which would be treated a simple list of keys using the current typing speed, without any special parsing for waits or control codes.

This is would be easier to type and understand, and is a bit less verbose:

Maybe something like:

- !Interactive
  keys:
    - h
    - e
    - l
    - l
    - o
    - 2s
    - ^X
    - n

becomes

- !Interactive
  keys:
    - !Str hello
    - 2s
    - ^X
    - n

Loving autocast so far!

[k9withabone]

This is a great idea! Thanks for the suggestion.

[DAmesberger]

Yeah, this was also my first thought for this great tool. Here is a PR #5 implementing the basics as a starting point. It does not yet take the current typing speed into account, but it supports the syntax suggested by @Billiam

[redcatbear]

Funny, how people have the exact same thought. I found autocast a couple of days ago thanks to word-of-mouth from a colleague and loved it from the first second.

The only thing I immediately missed was a line-by-line interactive input feature.

The reason is simple: autocast is perfect to script tutorials and it is good if the viewers can follow what you have to type. If you need to script creating a config file via say vim, scripting the key strokes one-by-one gets hard very quickly. Not to mention that the script gets very long!

Ideally lines could be even more compact in the script:

!Interactive
  lines:
    - This is a line
    - |
      These are
      multiple lines
    - !wait 2s

But the !Str variant mentioned by @Billiam is already a great improvement.

Thanks for making autocast @k9withabone, especially for making it open source!

[redcatbear]

By the way: shouldn't the milestone be 0.2.0 instead of 0.1.1 since this is a new feature, not a fix or refactoring? :-)

[k9withabone]

Thanks for the kind words. 😁

shouldn't the milestone be 0.2.0 instead of 0.1.1 since this is a new feature, not a fix or refactoring?

I'm following the Rust/Cargo rules of SemVer where the left-most non-zero digit is the major version. Going to v0.2.0 would imply a breaking change.

[redcatbear]

Ah, I learned something new today. I always assume that zero-versions had no way of expressing backward compatibility and as a user you always have to assume that a zero version can break interface compatibility at any given moment.

Because that is what the https://semver.org/ states:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

But it looks like the Rust community found that to weak of a guarantee and extended on the rules. Thanks for pointing out that detail.

This is pretty much in line with the Rust philosophy of being as explicit and unambiguous as possible. Good.