crossterm support

[conradludgate]

For #282, fixes #283.

Todo

• Fix failure to launch on 'up' keybinding
• Fix up/down keys in the TUI (ctrl-n/p work fine)

[conradludgate]

A curiosity, I've decided to try partial upgrade (tui 0.18 + termion) and it's still eating my arrow key inputs, but otherwise still responsive. So I'm not sure what's going on there

[ellie]

So I'm not sure what's going on there

Do you know what mode your terminal is in? Different modes can send different escape sequences, and it could be listening for the wrong ones

EG we switch to cursor mode here: https://github.com/ellie/atuin/blob/main/src/shell/atuin.zsh#L34

and perhaps termion doesn't like that

[conradludgate]

Do you know what mode your terminal is in? Different modes can send different escape sequences, and it could be listening for the wrong ones

Yeah, I was debugging and termion/crossterm never get the up/down. Which made me try again with our current version.

When running atuin search -i manually, it exhibits this behaviour.
When running from the keybinding, it is fine 🚀

[ellie]

When running from the keybinding, it is fine 🚀

Yup I had this when I was writing the initial implementation. Some applications can switch terminal mode and then don't switch it back, leaving other programs in a broken state

Terminal stuff has a lot of baggage 😂

But otherwise it all works? search -i is only really supposed to run from the binding anyway 🤔

[conradludgate]

I'm rebasing this branch now, I'll let you know

[conradludgate]

crossterm-rs/crossterm#396 :/

[conradludgate]

Ok, final conclusion since I've spent a while debugging this now. It's a combination of quite a few problems:

1. On ZSH, in our hook, stdin is not a tty. This is different to bash and fish
2. On macos, kqueue can't poll from /dev/tty
3. crossterm uses mio to poll from the tty, which uses kqueue on macos.

mio said they won't fix this specific behaviour, tbh I agree: tokio-rs/mio#1377

There's an open PR for crossterm to manually use select() for /dev/tty: crossterm-rs/crossterm#711

So far, this patch fixed it for me

[ellie]

@conradludgate looks like there's been some motion on that crossterm PR, and now this has been opened

crossterm-rs/crossterm#735

[conradludgate]

Yep. I've been following it. Hopefully it gets merged at some point

[conradludgate]

Just waiting for a new crossterm release after the merge ⏳

[pdecat]

Crossterm 0.26 is out 🎉
https://github.com/crossterm-rs/crossterm/releases/tag/0.26

[conradludgate]

I have updated to 0.26 crossterm and started vendoring a minimal subset of tui (now that it's maintenance is in question). It can be trimmed down further, but I don't want to go too minimal incase there are features we end up using.

[ellie]

LGTM!! Super excited we are finally ready to do this hahaha, thank you for working on this for so long.

[ellie]

Makes sense that we are vendoring this, but it would be nice to be able to remove it someday in The Future™️

[conradludgate]

Yeah, slowly we can either find a replacement or slim it down as much as possible to make the API as good for us as possible

[pdecat]

Hi @conradludgate @ellie,

I started to try and rebase my crossterm/inline PR #648, and figured that the version of tui-rs that was copied here is missing the bits needed from https://github.com/fdehau/tui-rs/pull/552/files#diff-554109cedfab40c7397c98d70e7a7449266358293b29ad5aa8db2f79e958122bR11 to make inline viewport possible.

Should I try and backport fdehau/tui-rs#552 on this local copy?

Any reason why git history from upstream was not preserved using git subtree?

Also, wouldn't maintaining a fork of tui-rs make things easier, at least until it is not needed anymore at all?

[conradludgate]

A full fork WG is already in the works and I'm taking part as a stakeholder. It seems we won't be vendoring it for long.

I'm not an expert in all the git features so I didn't think to use subtree. It sounds like it would be awkward though because we want it as a module and not a crate

[pdecat]

Ok, I guess should I copy the parts needed from the upstream inline PR then.

[ellie]

Ok let's do it 🚀