Overriding up/down key behaviour for list selection component

[mainrs]

Hey! I am trying to do a list selection component using rustyline while keeping the benefit of the other editing shortcuts like Ctrl-W. Is it somehow possible to not insert the previous history value when pressing up but rather execute custom logic? In my case, it would be "moving" the user selection one item up. The following picture is an example of what I am trying to do:

Maybe it's not the right crate to achieve this sort of things...

[gwenn]

There is bind_sequence. But you cannot execute custom logic yet.

[mainrs]

Would you be open to a PR that adds an enum variant with a function as its parameter that gets executed when the CMD is triggered through a key binding?

[gwenn]

I may be wrong but you will not be able to do what you want even with your own function. Because there is no primitive to print / clear lines on screen.

The nearest solution would be to:

• set your question as prompt,
• optionally provide a default input as default choice
• and implement your own Completer

But still, currently, you cannot customise how/when candidates are displayed (you can only choose between Circular / List ). And you cannot (as far as I know) customise the key used to iterate on candidates.

Another (hacky) solution would be to use a multiline hint (one line by choice) and synchronise your Hinter / Highlighter / ConditionalEventHandler (PR #492) to remember which choice / hint line is selected.

Did you look for another crate which may provide such feature out of the box ?

[mainrs]

I've taken a look at crossterm which allows for key polling. But the default input movements like Ctrl-W for example aren't implemented. So I'd have to create them from scratch (which isn't that much work, but still work). I am not to concerned about Vi/Emacs bindings to be honest, but having the actions you listed under all modes here would be definitely nice!

I'll probably end up writing a small wrapper around crossterm I think. I've tried to add a new enum variant, but I stumbled across generic type parameter issues where I had to add one to Cmd or I'd have to use fn as the variant value type. This would prevent lambdas that capture scope to work with the variant though. And in most use cases people probably want to capture the environment and make changes to it when registering custom logic using the Cmd::Function variant.

Thanks for taking your time and helping me out!

[MikeTheSapien]

Thanks for these discussion. I was looking for ways to bind particular keys with my custom functions as well.