refactor(os/input.c): rename os_inchar => input_get #30327

Problem:
The name `os_inchar` (from Vim's old `mch_inchar`) is ambiguous:
"inchar" sounds like it could be reading or enqueuing (setting) input.
Its docstring is also ambiguous.

Solution:
- Rename `os_inchar` to `input_get`.
- Write some mf'ing docstrings.
- Add assert() in TRY_READ().

1 files changed, 8 insertions, 9 deletions

diff --git a/src/nvim/event/loop.h b/src/nvim/event/loop.h
index 6ecc7cb781..da4852b836 100644
--- a/src/nvim/event/loop.h
+++ b/src/nvim/event/loop.h
@@ -16,15 +16,14 @@ struct loop {
   uv_loop_t uv;
   MultiQueue *events;
   MultiQueue *thread_events;
-  // Immediate events:
-  //    "Processed after exiting uv_run() (to avoid recursion), but before
-  //    returning from loop_poll_events()." 502aee690c98
-  // Practical consequence (for main_loop): these events are processed by
-  //    state_enter()..os_inchar()
-  // whereas "regular" events (main_loop.events) are processed by
-  //    state_enter()..VimState.execute()
-  // But state_enter()..os_inchar() can be "too early" if you want the event
-  // to trigger UI updates and other user-activity-related side-effects.
+  // Immediate events.
+  // - "Processed after exiting `uv_run()` (to avoid recursion), but before returning from
+  //   `loop_poll_events()`." 502aee690c98
+  // - Practical consequence (for `main_loop`):
+  //    - these are processed by `state_enter()..input_get()` whereas "regular" events
+  //      (`main_loop.events`) are processed by `state_enter()..VimState.execute()`
+  //    - `state_enter()..input_get()` can be "too early" if you want the event to trigger UI
+  //      updates and other user-activity-related side-effects.
   MultiQueue *fast_events;
 
   // used by process/job-control subsystem