dd_lightbar_menu: str_is_utf8() seems to return true sometimes when a string doesn't have UTF-8, so that is now commented out for now
dd_lightbar_menu: str_is_utf8() seems to return true sometimes when a string doesn't have UTF-8, so that is now commented out for now Having that appear true when it actually doesn't have UTF-8 characters is causing the lightbar menu to not display the whole menu item in some cases (perhaps due to the DDLightbarMenu logic).
Merge request reports
Activity
assigned to @rswindell
All ASCII characters (and thus, ASCII strings) are also valid UTF-8 characters/strings.
So... I'm not clear on what you mean by "sometimes"? If there's, say, a CP437 character in a string, then that string would not be a valid UTF-8 string, but all purely ASCII strings are valid UTF-8 strings.
The JSDOC for this function says "Return true if the specified string contains only valid UTF-8 encoded and US-ASCII characters" - so I'm not clear if/how this function isn't behaving as expected or you just didn't read the "US-ASCII" part?
I haven't thoroughly tested it, so I don't know if it happens in all cases, which is why I said "sometimes". I understand that str_is_utf8() is meant to return true if the string contains only valid UTF-8 encoded and ASCII characters.
The issue I'm seeing is with some of my mods - For instance, with my area choosers, they're taking the message group, sub-board, file libraries, and directory names from the BBS's configuration, and it's using those in lightbar menu items. I'm not using any UTF-8 characters in my area choosers, and for the group/sub-board/library/directory names, I had the impression that those don't have UTF-8 characters, but str_is_utf8() is returning true for the text strings in the menu item, and that's causing some display issues in my area chooser mods.
Basically, this change reverts back to previous behavior which did not use str_is_utf8(), and that is enabling my other mods to work as expected for now.
mentioned in commit 654b6f76