You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 theINTERNAL_EVENT_READER
mutex if anEventStream
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.
The text was updated successfully, but these errors were encountered: