-
Notifications
You must be signed in to change notification settings - Fork 3
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
[FIX] Fix prompt issues #381
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
readline needs "zero-length" characters to be wrapped in special markers: `\001` and `\002`. `\001` and `\002` are defined in `readline.h` as `RL_PROMPT_START_IGNORE` and `RL_PROMPT_END_IGNORE` respectively. Source: https://tiswww.cwru.edu/php/chet/readline/readline.html#index-rl_005fexpand_005fprompt
…l files" These special markers are only needed for prompts when most likely there is a call to readline behind it. This reverts commit 221dc86.
Converted to draft to also fix the same problem with the emoji. The emoji is 4 bytes long but only takes up 2 characters on screen. This also causes issues. |
Mentions of using the markers like this are also in the `man` of readline.
The `\1`& `\2` markers are only needed for readline, so for us it means only for the prompt.
Once the color escape sequences caused no issues anymore, there were sometimes still small issues. '🌊' is a 4-byte character, but only takes up width of 2 characters, which caused those remaining issues with readline. The solution is to use hexcode representation of '🌊' to be able to mark 2 out of the 4 bytes as invisible characters for readline. I found out about this workaround here: https://stackoverflow.com/a/56688167/24880406
itislu
force-pushed
the
fix-color-prompt-issues
branch
from
September 24, 2024 22:10
6f52b6f
to
0f07b8f
Compare
For me it is clear. but there are too many commits a bit confused. Maybe next time you could squash them |
LeaYeh
approved these changes
Sep 26, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now there are no weird issues with the prompt anymore! 🎉
readline needs "zero-length" characters to be wrapped in special markers:
\001
and\002
.\001
and\002
are defined inreadline.h
asRL_PROMPT_START_IGNORE
andRL_PROMPT_END_IGNORE
respectively.I use
\1
and\2
bc they're shorter. Mentions of using the markers like this are also in theman
of readline.Source: https://tiswww.cwru.edu/php/chet/readline/readline.html#index-rl_005fexpand_005fprompt
Once the color escape sequences caused no issues anymore, there were sometimes still small issues. '🌊' is a 4-byte character, but only takes up width of 2 characters, which caused those remaining issues with readline.
The solution is to use hexcode representation of '🌊' to be able to mark 2 out of the 4 bytes as invisible characters for readline.
I found out about this workaround here: https://stackoverflow.com/a/56688167/24880406