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.

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

Improving queries against the host terminal #763

Open
the-mikedavis opened this issue Mar 5, 2023 · 0 comments
Open

Improving queries against the host terminal #763

the-mikedavis opened this issue Mar 5, 2023 · 0 comments

Comments

@the-mikedavis
Copy link
Contributor

Is your feature request related to a problem? Please describe.

Crossterm's API is really nice for sending commands to the host terminal but is more limited for querying information. Two existing examples in the codebase are the cursor position query and the check for whether the host terminal supports Kitty's keyboard enhancement protocol. It would also be nice to query for other information like the host terminal's title (#617), the current cursor shape, and whether the terminal supports synchronized output (#756).

The current queries work by polling internal events but that can be a problem if you are also reading regular events concurrently, for example via an EventStream. The internal event reader is guarded by a mutex that ensures at-most-one reader at a time, so you can accidentally lock up your querying thread waiting for the INTERNAL_EVENT_READER mutex if an EventStream already holds the mutex. It also takes a fair amount of code to add a new query (#732) while adding new commands is relatively easy.

Describe the solution you'd like / Describe alternatives you've considered if any

Ideally I think you should be able to ask queries at the same time as reading regular crossterm events. Query responses like primary device attributes and active keyboard enhancement flags are always unrelated to regular crossterm events, so I think a reader for query responses should be able to be entirely separate from a reader for regular events.

Implementation-wise, I'm not very familiar with async things and futures (😅) so coming up with a nice and idiomatic system for this might be beyond my capabilities. Maybe channels would be a nice solution to the async problems and a Query trait (similar to the Command trait) would be a nice way to cut down on the code for adding a new query? I'll think about this some more and open up a PR if I have any clever ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant