-
Notifications
You must be signed in to change notification settings - Fork 263
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
Improve word and file name completion with non-ASCII characters #946
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Already included in https://git.sr.ht/~mcepl/vis and it seems to work just fine.
vis-menu.c
Outdated
valid = textvalidn(t, w-4); | ||
if (valid < 0) | ||
die("invalid UTF-8 sequence"); | ||
for (i = MAX(valid, 0); i < tw; i++) buf[i] = '.'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about calling die()
here. It seems unnecessary.
There are definitely still some issues with handling of non-ASCII characters I'm thinking of applying it apart from the call to |
On August 10, 2023 5:59:08 PM GMT+02:00, Randy Palamar ***@***.***> wrote:
There are definitely still some issues with handling of non-ASCII characters
after applying this but overall I think this improves the situation.
I'm thinking of applying it apart from the call to `die()`. Any objections?
I'm also for removing the "die()" before applying. Thanks for picking up this PR!
…--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
|
Before we were not taking non-ascii characters into account properly. With this patch we still mix byte counts and "grapheme cluster" (i.e. complete glyphs that are rendered in a terminal cell) counts but the code should be less broken in the more common case now.
The '[:alnum:]' set does not include non-ascii text which results in the non-ascii text being replaced with newlines. Using the '[:blank:]' set with no complement flag fixes this issue.
976bf60
to
711447a
Compare
Applied, thanks for the patch! |
These two commits fix this issue #941.
Note that
vis-menu
is still not handling Unicode correctly (it's still not differentiating properly between bytes and "grapheme clusters", i.e. printable glyph-combinations, when calculating lengths). With these changes we are at least able to have a working support for non-ASCII characters in the simple case.