Skip to content
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

Merged
merged 2 commits into from
Aug 14, 2023

Conversation

Shugyousha
Copy link
Contributor

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.

@rnpnr rnpnr mentioned this pull request Aug 1, 2023
8 tasks
Copy link
Contributor

@mcepl mcepl left a 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] = '.';
Copy link
Collaborator

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.

@rnpnr
Copy link
Collaborator

rnpnr commented Aug 10, 2023

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?

@Shugyousha
Copy link
Contributor Author

Shugyousha commented Aug 14, 2023 via email

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.
@rnpnr rnpnr force-pushed the try-to-preserve-codepoints branch from 976bf60 to 711447a Compare August 14, 2023 14:40
@rnpnr rnpnr merged commit 711447a into martanne:master Aug 14, 2023
24 checks passed
@rnpnr
Copy link
Collaborator

rnpnr commented Aug 14, 2023

Applied, thanks for the patch!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants