mWalrus@7a09a1c
I began some work in src/items.rs just now regarding moving away from Text, Line and Span. I've tried to bring down allocations as well.

While I think my approach would improve performance a bit, I'm not sure whether I like it from a readability perspective and there are still improvements to be made in both areas.
I couldn't come up with an obvious way to avoid having to own the unstyled string as it is constructed in a couple different ways, but I'll keep prodding when I have time! :)

I would like your opinions on my current work before I continue any further!

I've yet to test any of this as my current branch doesn't compile :P

@mWalrus sweet. Looks like a good start! I'll try add some comments.

I actually realized something that might be useful.

May not need to store display

We may not need to use the display on an Item. The target_data mostly represents what would be needed. (trading a bit of compute cost towards rendering instead of prepping display on each update).

For example, if an Item has a target_data: TargetData::HunkLine { .. }:

    HunkLine {
        diff: Rc<Diff>,
        file_i: usize,
        hunk_i: usize,
        line_i: usize,
    },

Then we could render the line of the hunk by reading this struct

1. Take the ID of the hunk and check if it's in cache
2. Highlight the hunk if not in cache
3. Take the highlighted hunk and extract the line, print it to screen.

This way highlights won't be computed for Items that are not visible -> performance win.

Widgets

I'd love for each Item to be a Widget. But you can't remove Widgets from the Ui in Termwiz.
(and they seem kinda expensive).
Although I did copy and tweak the Widget/Ui/Layout code from Termwiz into src/layout.

Still reconsidering my choices and I've been looking at more immediate rendered layout systems like https://github.com/nicbarker/clay.

May not need to store display

We may not need to use the display on an Item. The target_data mostly represents what would be needed. (trading a bit of compute cost towards rendering instead of prepping display on each update).

For example, if an Item has a target_data: TargetData::HunkLine { .. }:

    HunkLine {
        diff: Rc<Diff>,
        file_i: usize,
        hunk_i: usize,
        line_i: usize,
    },

Then we could render the line of the hunk by reading this struct

1. Take the ID of the hunk and check if it's in cache

2. Highlight the hunk if not in cache

3. Take the highlighted hunk and extract the line, print it to screen.

This way highlights won't be computed for Items that are not visible -> performance win.

Ahh, true! That's a neat idea. I think that should be doable. Looking into that now :)

I've kind of realized a few things since i started:

• The screen module deals with single lines, which becomes convenient when scrolling and navigating.
• Using Termwiz widgets for modeling each single line in screen becomes messy
  • You can only add children to the ui tree, not remove
  • We would need to keep a list of line-widgets and then re-use them on a refresh of items.
• A lightweight immediate-style layout library might be easier to work with.
  • Ratatui kind of does this, but it doesn't allow auto-sizing, yet still pulls in an advanced layout engine: cassowary
  • clay Seems simple and sufficient for Gitu, but it's Rust bindings are pretty young.

@altsem,
Saw you mention something about a layout library you started working on but can't find the comment nor a repo on your profile. Is this something you're still considering implementing?

@mWalrus i did! But realised it it had some flaws, and decided to stop.
Managed to fix those issues yesterday tho.
Will head for vacay soon, but might be a way forward.

I had a mockup of the layout in Gitu.

I'll see if I can wrap it up, and I'll share it here again

@altsem,

Alright, I see, cool! I'd love to have a look around that repo.

Vacation is approaching for me as well finally! :)

https://github.com/altsem/layzer Public again!
Largely inspired by this: https://www.youtube.com/watch?v=by9lQvpvMIc

There's a test in there to try render out a mock of Gitu's UI.
Still need to figure out how styles would get merged in Gitu when text-wrapping is done.

I'm closing this down in interest of time. If I were to start again, I'd look into incorporating a library like Clay.