upgrade papergrid to a later version of unicode-width

[fdncred]

@zhiburt we're running into issues with nushell. we can't upgrade to crossterm 28.1 and ratatui 28.1. I think this is because tabled has a dep on papergrid which locks the unicode-width dep at 0.1.11. Would you mind updating papergrid/tabled with a later version?

tabled/papergrid/Cargo.toml

Line 16 in 300c07b

unicode-width = "=0.1.11"

[zhiburt]

Yep....................
..........................
..........................

Something I must do.
I'll ponder about it in short, hopefully.

To be honest I haven't had a good idea how to fix it.
Though wasn't thinking a lot :)

ref #423

[pycui]

+1 on this, it's causing version conflicts since unicode-width is widely used in other crates. Appreciate if we can fix it

[zhiburt]

Hi there

What do you think if I just fork unicode-width and that's it? 😄
IDK why I haven't thought about it at first.

[zhiburt]

Somewhat I started to think that maybe this nushell/nushell#13088 (comment) was not an actual issue.

At this point.
Seems like I haven't investigated it deep enough.

[fdncred]

maybe there's some other crate other than unicode-width that you can use? I'm not sure such a thing exists. It's a pain not being able to update ratatui and other deps. If you fork unicode-width, you could rename it to tabled-unicode-width so that it doesn't conflict with the other one maybe?

[zhiburt]

If you fork unicode-width, you could rename it to tabled-unicode-width so that it doesn't conflict with the other one maybe?

Exactly
And it's a 5 minute job.

I guess It's a good solution unless I figure it out completely :(

[fdncred]

I think you should go ahead and do it. The worst that can happen is that you have to revert or change it. It's just software, it can be changed again.

[joshtriplett]

I've read through the entirety of unicode-rs/unicode-width#55 and unicode-rs/unicode-width#64 , and as far as I can tell, I think the new behavior of unicode-width is more correct for tabled's purposes (e.g. handling the width of emoji correctly), as long as tabled never feeds control characters to unicode-width. (For control characters, unicode-width will guess that the terminal might choose to render a character-sized replacement character, but some terminals may not render such characters at all; there's no consistent answer here other than to not handle control characters. I think it'd be reasonable to tell people to just not put control characters into table cells and expect reasonable results.)

Rather than forking unicode-width to preserve the old behavior (which was incorrect for, among other things, many composed emoji using ZWJ), I think it would make sense to port to the new behavior of unicode-width and have a dependency on that version of unicode-width.

[joshtriplett]

I've published a PR at #430 to use current unicode-width and improve width handling.

[joshtriplett]

I think this issue can now be closed.

[zhiburt]

Must be released;
Eventually 😅

tabled = "=0.17.0"