search

zhiburt / tabled

An easy to use library for pretty print tables of Rust structs and enums.
MIT License
2.01k stars 84 forks source link

upgrade papergrid to a later version of unicode-width #426

Open fdncred opened 1 month ago

fdncred commented 1 month ago

@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?

https://github.com/zhiburt/tabled/blob/300c07bd53c945671e8115811c1689cb1353feff/papergrid/Cargo.toml#L16

zhiburt commented 1 month ago

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 commented 4 weeks ago

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

zhiburt commented 3 weeks ago

Hi there

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

zhiburt commented 3 weeks ago

Somewhat I started to think that maybe this https://github.com/nushell/nushell/issues/13088#issuecomment-2226557157 was not an actual issue.

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

fdncred commented 3 weeks ago

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 commented 3 weeks ago

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 commented 3 weeks ago

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 commented 2 weeks ago

I've read through the entirety of https://github.com/unicode-rs/unicode-width/issues/55 and https://github.com/unicode-rs/unicode-width/issues/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 commented 2 weeks ago

I've published a PR at https://github.com/zhiburt/tabled/pull/430 to use current unicode-width and improve width handling.

joshtriplett commented 1 week ago

I think this issue can now be closed.