Demonstrating auto completion does not seem to be possible

[i-love-coffee-i-love-tea]

I would like to use autocast to demonstrate my generic CLI script's auto completion features.

As far as I understand this is currently not possible. Control-I should send a tab character, so I tried to do it with this config.

- !Interactive
  command: 'cli '
  keys:
    - ^C
    - i
    - ^C
    - i

This does not work like I expected though. I think it is because it executes the command before sending the key codes. It would be nice, if one could defer execution with a flag, in which case the user would have to send a new line character in the keys section to manually complete the command. For example:

 !Interactive
 command: 'cli '
 defer_execution: true
 keys:
    - ^C
    - i
    - ^C
    - i
    - some_autocomletion_input
    - ^C
    - i
    - \n

Cheers!

[k9withabone]

I think it is because it executes the command before sending the key codes.

This is correct, autocast first sends the command to the shell, adding new line character(s) to end of it. This is what you want to start an application which is interactive, for example, an editor or other TUI app.

Perhaps instead of defer_execution there should be a raw_command option? raw_command: true would cause the command to be sent to shell as is without adding new line character(s). I'm not sure if that solves your problem but its worth trying.

I'm busy with other things at the moment, so it might take me a while to implement this.

[i-love-coffee-i-love-tea]

I too thought it would be worth a try and tried to do it myself with the limited Rust knowledge I have. I removed the typed newline in rust by using send instead of send_line. I think it worked, because now the simulation hangs and does not finish anymore. Then my next problem was that \n didn't work (i tried my luck). From the tests in the code I understand that ^m is Carriage Return, so I tried this, but it also failed to make the recording finish. It seems there is a tiny bit more logic missing to achieve what I want.

Just to let you know.

[i-love-coffee-i-love-tea]

I wanted it so bad that I took the time to learn the language and wrapped my head around the code. Now I have a demo running.

I implemented the following

• added the raw_command flag to Interactive commands
• printing a new prompt if there is shell data at the beginning of keys_to_events. It may be good to separate the auto complete support into a different command type instead of using Interactive for it. CompletedCommand, for example. Although it should also support a list of individual keys like Interactive IMO.

And to make it more usable

• support for multi character sequences in Interactive commands, with applied key delay (see Key::CharSequence)
• added output for <TAB> and <ENTER> in Interactive commands to make invisible key presses visible in auto complete demos. Maybe this should be optional?

I made a demo.yaml and created a new demo.gif showing the result. What do you think?

https://github.com/i-love-coffee-i-love-tea/autocast

[k9withabone]

Nice job!

It may be good to separate the auto complete support into a different command type instead of using Interactive for it.

I agree that completions should be new command. Looking at your changes it seems to have complicated things significantly to try to integrate it with interactive. I think that adding support for completions would have to be shell dependent as every shell seems to handle completions differently. As I said in the README, I don't have any experience with shells other than bash, and I don't really know how completions work in bash. Maybe there is a way that you can get completions for an input with a bash builtin? That way we could separate the retrieval of completions from generating the output.

support for multi character sequences in Interactive commands, with applied key delay (see Key::CharSequence)

I mentioned this in #5, but I think it would be better to change how the keys field of Instruction::Interactive is deserialized rather than adding a new Key variant. It would keep the output generation simpler.