Downstream `ratatui` into `helix-tui`

[RoloEdits]

It was briefly mentioned in #15229, but I think it would be a good idea to port the changes over from ratatui into helix-tui. Both started as forks of tui-rs, so its base is similar enough that it should be pretty straight forward to do still.

There are probably a lot of outstanding bug fixes that would probably be solved as well. And matching the structure as close as possible would allow straightforward ways to apply smaller patches going forward. ratatui also gets a lot more eyes on it as far as TUIs are concerned, so correctness fixes would, in theory, be exposed and fixed there first. It would also allow us a very clean way to adopt the benchmarking structure they have, making it much nicer to work on performance related features.

Even if its not chosen as a goal to try to keep parity on a regular basis, even just updating now would come with the value of the fixes that have happened in the meantime. Keeping up to date would also allow contributors who are familiar with ratatui so follow the APIs they already know. Adding ui elements, if they have a good analog, from rataui would also be much more straight forward. I think this kind of cross pollination is worth it in the long run.

The main parts to bring over would be in the ratatui-core crate. The biggest diff change seems to be that they broke out the single file into sub-modules for many things (and added lots of tests). After that it looks like a lot of the APIs have been refined, for example not taking a Vec, but an Iterator instead. I see a quite a few bit of uses of vec![] that could go away, removing these extra allocations. The other somewhat large (as far as diff) change would be that Spans<'_> got renamed to Line<'_>. From there its porting over new functions and applying fixes to existing functions.

This is something I would be willing to undertake!

It would be done over the course of a few PRs. First one would probably be the sub-module breakout, with no other changes. Then, rename Spans to Line. From there, applying fixes to the existing functions would come. Probably done on a per sub-module basis. Small changes might come to accommodate the changes, but the scope would remain with that as a goal. Once the existing functions are gone through and patched, next would be the adopting the new APIs, and changing old ones if they weren't already changed as part of fixes. Again, probably per sub-module. At the end of this, it should be translated over. Breaking it up this way should hopefully make it much easier to review.

From what I can see, it should be straight forward, but I do have a question as to why some parts of helix-tui were taken out, like Rect and Style, and put into helix-view. Is it not possible to invert the dependency? Was this done with a non-tui in mind for the future?

Overall, as I said, this would be something I would be willing to undertake. But I know review time is hard to come by. I think I can keep the changes straight forward enough to keep reviews as much of an A|B comparison as possible, but life programming loves to throw wrenches.

[matoous]

From what I can see, it should be straight forward, but I do have a question as to why some parts of helix-tui were taken out, like Rect and Style, and put into helix-view. Is it not possible to invert the dependency? Was this done with a non-tui in mind for the future?

As far as I understand, it was not a deliberate choice but rather an organic side-effect and the crates are not organized the way they ideally would be. I had similar question and #10074 might shed a bit more light on this topic.

[pascalkuthe]

I am not sure about that. We use a different rendering backend and have many customanizations and in many way significantly diverged from the original crate. Also ratatui made some choices and assumptions that I don't necessarily agree with. Considering its such a core part of Helix I would be inclined to keep it in-tree so we have more control but I am not categorically opposed

[Aaalibaba42]

Downstreaming is maybe a bit extreme, I was more imagining making the structure closer so that the patches can be downstreamed without much hassle, much like #15210 (even though the final solution to this was not the same as ratatui's)

[RoloEdits]

Yeah, I say "downstream", as in essence this will be the action taken, but we will still own helix-tui. Its just bringing it more inline with ratatui. Any other changes that have already been made, or other optimization we do, will stay. Like they use CompactString in Cell, but we can use ArrayString, for example.

The bulk of the diff will be the structural changes and added tests. Looks like they also use a maintained fork of cassowary, so upgrading to that would be something done as part of this "downstream". It will be things like this. Updating some algorithms, like the diffing one, should help mitigate outstanding bugs. These will be submitted as individual PRs. So in essence it reaches the "patches can be downstreamed without much hassle" goal. There is no goal to lose autonomy of changes we make, because as pascal said, its such a core part of helix. We should own it.