[unison-cli] Fix prompt rendering after reverse search in Haskeline#6149
Conversation
|
@MauScheff Cool! But on my terminal (iTerm), I don't think I'm seeing the problematic behavior you describe. I seem to be able to ctrl+r, press enter, and not get any trailing text. Could you lay out the steps to reproduce one more time and maybe share a screenshot or terminal recording? Additionally, could you share a link to the Haskeline documentation where you say it recommends we perform this step? |
|
@MauScheff Ah, I just tried this branch out to see if it fixes an issue I noticed after merging a new ANSI backend to Haskeline (code here), and, well, it does! |
|
One improvement might be to detect whether \SOH ... \STX are already in the prompt, and not double up if so. But this is great, thank you. |
mitchellwrosen
added
the
ready-to-merge
|
Looks like our |
|
@mitchellwrosen I was using iTerm2, with zsh + oh-my-zsh and it could have been that setup, I'm still using zsh + oh-my-zsh but I'm now using Ghostty which I really like. I observed the same behavior on both setups and demonstrated it to @rlmark during a screen share. It was very annoying to say the least, so I decided to vibe code it to fix it (I dunno why codex says Haskeline recommends this lol, but it worked, if you have a better fix that's great too), and I could see the fix working and that was good enough for me.I hope this is fine, wouldn't like to have to roll back to the old ucm just to prove this (very short on time at the moment). I guess since I checked in from trunk, it upgraded my codebase and made it incompatible with the old ucm, and I had to just delete the old ucm and use the one from trunk from now on. Hope this works. |
2 participants
Overview
What does this change accomplish and why?
Fixes terminal artifacting after Ctrl‑R reverse search by
marking ANSI prompt sequences as non‑printing for Haskeline.
i.e. How does it change the user experience?
After pressing Enter from reverse search, the line no longer
shows duplicated “tail” text.
i.e. What was the old behavior/API and what is the new
behavior/API?
Old: Prompt ANSI sequences were counted as printable width,
causing cursor misplacement and residual characters.
New: ANSI sequences are wrapped with SOH/STX so Haskeline
ignores their width.
Include "before and after" examples if appropriate. (You can
copy/paste screenshots directly into this editor.)
(Screenshots can be added.)
List any Github issues that this PR closes, in closing-
issues-using-keywords format.
Implementation approach and notes
Wrap ANSI escape sequences in the prompt passed to getInputLine
using SOH/STX markers, as recommended by Haskeline, so cursor
positioning is correct.
Interesting/controversial decisions
No major alternatives; this is the standard Haskeline approach for
colored prompts.
Test coverage
this change, or is it somehow covered by existing tests?
No automated tests; manual verification only.
part of this PR or as a separate issue) or do you think it’s
adequate?
Probably adequate for now; terminal interaction is hard to test.
practical to do for this change, mention that. Include
screenshots.
Tested manually by running UCM, using Ctrl‑R on a long history
entry, and confirming the line renders correctly after Enter.
Loose ends
None.
Final checklist
used to create release notes, so please make it descriptive of
the change itself, which may be different from the initial
motivation to make the change.
changed over time.
changed behavior.
files are up-to-date instead.