Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Lost keys in vi launched from broot #73

Closed
Canop opened this issue Nov 4, 2019 · 3 comments
Closed

Lost keys in vi launched from broot #73

Canop opened this issue Nov 4, 2019 · 3 comments
Assignees
@Canop
Labels
bug Something isn't working

Comments

@Canop
Copy link
Owner

Canop commented Nov 4, 2019 •
edited

This happens when broot isn't closed when vi is launched in the same terminal: some of the keys are eaten and not available for vi.
@Canop Canop added the bug Something isn't working label Nov 4, 2019
@Canop Canop self-assigned this Nov 4, 2019
@Canop
Copy link
Owner Author

Canop commented Nov 4, 2019

workaround: change the verb to add from_shell=true:

[[verbs]]
invocation = "edit"
key = "F2"
shortcut = "e"
execution = "$EDITOR {file}"
from_shell = true

@Canop
Copy link
Owner Author

Canop commented Nov 4, 2019

This is related to this unsolved bug in crossterm: crossterm-rs/crossterm#295
The underlying thread and file descriptors aren't closed when the sync_reader is dropped.

@Canop
Copy link
Owner Author

Canop commented Nov 4, 2019

This is totally solved when using the stop_reading_thread function introduced by this PR: crossterm-rs/crossterm#308

As soon as this PR is merged into crossterm and released, I'll release a new version of broot.

Canop added a commit to Canop/termimad that referenced this issue Nov 4, 2019
@Canop
incorporate crossterm 0.13.2 which fixes a regression on input reader
0ac7270 
References:
* Canop/broot#73
* crossterm-rs/crossterm#308
@Canop Canop closed this as completed in ffe44da Nov 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Canop Canop

Labels
bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@Canop