| Age | Commit message (Collapse) | Author |
|---|
|
|
|
navigator
refs #1611
|
|
|
|
refs #1125
|
|
|
|
|
|
|
|
refs #1230
|
|
* fix: switch prefix ASCII input source on the foreground client
The macOS prefix ASCII-switch ran in the headless server, whose
TISCopyCurrentKeyboardInputSource read is a stale per-process cache
(refreshed only via a main-run-loop notification the server never pumps),
so prefix could leave the terminal on the wrong input source.
Forward it to the foreground client, like clipboard: sync_prefix_input_source
emits AppEvent::PrefixInputSource as an intent; the server forwards it to the
foreground client and the monolithic app applies it in-process via
RealPrefixInputSource, which pumps its main run loop before the stale TIS read.
Key it on Mode::wants_ascii_input so multi-level prefix commands keep ASCII
until returning to the terminal, and restore the IME for rename text entry.
Adds ServerMessage::PrefixInputSource to the already-unreleased protocol 15.
refs #774
* fix: keep prefix input-source switch out of the headless server process
An App-internal drain (the exhaustive drain at the top of
handle_api_request, reachable from prefix-key runtime mutations) can
consume a queued PrefixInputSource intent before the server's
forwarding drain sees it, applying the TIS switch in the headless
server process and stranding the restore state. Gate the in-process
switch on App.local_input_source_switch, disabled by the headless
server alongside the other local side effects, so a swallowed intent
degrades to a skipped switch. Widen the forwarding-bypass maintenance
test to the handle_internal_event_with_prefix_sync wrapper.
refs #774
* docs: clarify prefix input-source comments and flag docs
refs #774
* fix: bump protocol for prefix input source
refs #774
---------
Co-authored-by: Ogulcan Celik <ogulcancelik@gmail.com>
|
|
refs #448
|
|
refs #842
|
|
refs #271
|
|
refs #675
|
|
refs #318
|
|
|
|
|
|
Add manifest-driven plugin actions, event hooks, pane entrypoints, link handlers, and host APIs.
Support plugin link, GitHub install, build commands, installed plugin registry, pane movement, runtime context, and plugin docs.
|
|
refs #299
|
|
|
|
|
|
|
|
refs #486
|
|
refs #421
refs #330
related discussions:
https://github.com/ogulcancelik/herdr/discussions/422
https://github.com/ogulcancelik/herdr/discussions/438
https://github.com/ogulcancelik/herdr/discussions/442
|
|
On macOS, opt-in under [experimental], temporarily switch the host input
source to the current ASCII-capable layout while prefix mode is active so
prefix commands register even when a CJK IME is composing, then restore the
previous input source when prefix mode exits or is cancelled. No-op when the
current source is already ASCII-capable, on non-macOS platforms, or when any
input source call fails. Pane text input is unaffected.
Also pin next_resize_poll in next_loop_deadline_includes_selection_autoscroll_deadline
so the selection autoscroll deadline stays the earliest; the default resize
poll could otherwise beat it and flake the assertion.
refs #400
Co-authored-by: Can Celik <ogulcancelik@gmail.com>
|
|
refs #398
Co-authored-by: Can Celik <ogulcancelik@gmail.com>
|
|
refs #360
Co-authored-by: Can Celik <ogulcancelik@gmail.com>
|
|
refs #148
|
|
refs #369
|
|
refs #350
|
|
refs #231
|
|
|
|
|
|
|
|
refs #287
|
|
refs #282
|
|
refs #217
Co-authored-by: Can Celik <ogulcancelik@gmail.com>
|
|
refs #157
|
|
|
|
refs #137
|
|
refs #236
|
|
|
|
refs #149
|
|
tracking
When the focused pane requests ?25l (cursor hidden) but paints its own
cursor — common in TUIs like Claude Code, pi, and codex — macOS native
input methods stop tracking the candidate-window position. CJK users
(Chinese / Japanese / Korean) cannot see candidate windows follow as
they type. Setting [experimental] reveal_hidden_cursor_for_cjk_ime = true
exposes the focused pane's cursor anchor to the outer terminal regardless
of the pane's hidden-cursor request, restoring IME tracking for CJK input.
[experimental] cjk_ime_agents is an optional allow-list. When empty,
the reveal applies to any focused pane. When non-empty (e.g.
["claude", "codex"]), the reveal only applies if the focused pane's
detected agent matches one of the listed names. This lets users enable
the workaround only for AI-agent TUIs that paint their own cursor,
leaving plain shells and other programs untouched. Accepted names: pi,
claude, codex, gemini, cursor, cline, opencode, copilot, kimi, kiro,
droid, amp, grok, hermes. Unknown names are ignored.
When the pane reports no cursor position (cursor_state returns None for
some TUIs), the anchor falls back to the pane's top-left so a stable
IME hint is always available.
[experimental] cjk_ime_cursor_shape (default "steady_block") controls
the DECSCUSR shape rendered for the revealed cursor; six variants are
accepted: block, steady_block, underline, steady_underline, bar,
steady_bar.
Trade-off when enabled: a hardware cursor will be visible in the outer
terminal for apps that hide the cursor without painting a replacement.
Default false preserves the behavior set in 2c95071. Pair the reveal
with cjk_ime_agents to scope it to specific TUIs.
Manually verified on macOS 26.5 aarch64 with system Pinyin IME against
Claude Code: candidate window tracks cursor with flag enabled, returns
to anchored-at-start behavior with flag disabled.
refs #149
|
|
refs #154
|
|
|
|
refs #154
refs #201
refs #202
refs #219
|
|
refs #196
|
|
|
|
|
|
* feat: configure sidebar min/max width via [ui]
Expose the previously hardcoded MIN_SIDEBAR_WIDTH / MAX_SIDEBAR_WIDTH
clamps as [ui] sidebar_min_width / sidebar_max_width. Defaults remain
18 / 36 so existing configs are unchanged. Hot-reload is wired through
the existing [ui] block; reload re-clamps the live width to the new
bounds so tightening takes effect immediately.
Reject inverted bounds (min > max) at every entry point so a bad config
can never reach u16::clamp(min, max), which panics: App::new falls back
to defaults, and apply_live_config treats the whole [ui] section as
invalid and returns a partial reload report.
refs #132
* test: keep sidebar reload width within bounds
refs #132
---------
Co-authored-by: Ogulcan Celik <ogulcancelik@gmail.com>
|
