Unicode width of a byte slice? about bstr HOT 3 CLOSED

This seems like similar rationale to why some of the other unicode things are in here, but I wanted to know if a PR implementing this would be accepted before doing anything.

Yes, indeed. I believe what you've outlined is a good fit for bstr.

So I think the API would look something like fn unicode_width(&self, cjk: bool) -> usize. It's worth noting that the unicode-width crate exposes separate functions, but having one be the default feels a little non-ideal, and this reduces the API surface anyway. An enum would also work but the only name I can think of for the non-cjk variant is, well, NonCjk (to be clear: Latin wouldn't be accurate). So, a bool punts on having to make that decision, even though it might be considered slightly opaque.

Yeah, I think using a bool here is probably the worst possible choice. :-( I'd really like to avoid it. What about unicode_width_noncjk and unicode_width_cjk?

from bstr.

For an update: I've determined that what I needed was a bit more subtle than unicode width (well, I had known this, but I was hoping that it wouldn't be too hard to massage the unicode-width output into something that worked well in practice).

What I actually need/needed seems to be somewhere between a modified unicode width of the char for single-char graphemes, and 2 for any graphemes which are emoji. Additionally, I needed to allow for the chars (emoji) which had their width change in Unicode version 9. This works okay but is very ad-hoc, and still falls over for characters like e.g. ﷽ (admittedly, there may be no handling cases like that), and some others.

Anyway I don't have an algo that I'm that happy with yet (just one that worked well enough for me to move on), and even if I did, something that ad-hoc and heuristic driven probably isn't a great fit for a lib bstr in the first place.

(All that said a spec-compliant implementation of the unicode east-asian-width computation probably still would be an okay fit for bstr -- it's just not a thing I'm inclined to spend effort on)

So this is a long winded way of saying I'm probably not going to be the one to fix this, and so I'm closing it for now. Feel free to reopen if you'd rather wait for someone else to do it.

from bstr.

Agreed! Thank you. If someone else wants a spec compliant version, then I would still be happy to accept that for bstr.

from bstr.