Fix file history for sizes <= 1200 entries

[cruessler]

This Pull Request partly fixes #1560.

There is a lot of context in the comment I included in the change. As far as I can tell, this fix works for histories that have <= 1200 entries. If we want a solution that addresses the issue for larger histories as well, we can hopefully take this PR as a starting point. For the time being, I thought it would be best to open the PR in this state already, so we have more context and can start a discussion.

It changes the following:

• It brings self.items.index_offset always in sync with self.table_state by always using 0 as the items’ offset

I followed the checklist:

• I added unittests
• I ran make check without errors
• I tested the overall application
• I added an appropriate item to the changelog

[extrawurst]

so this is still broken for files with history items >1200?

[cruessler]

Yes, the file history’s entries are loaded here: https://github.com/cruessler/gitui/blob/e40e095993dc2c7c652296a38cdb9ba2b487b7f4/src/components/file_revlog.rs#L231. The code reads &git_log.get_slice(0, SLICE_SIZE)?, so this will always load the first 1200 items, never items beyond that limit.

What we could also do is maybe introduce padding in get_rows, i. e. we could prepend the correct number of empty rows so that the offset used by render_stateful_widget would be valid. Downside: added complexity and a few bytes of additional memory used.

[extrawurst]

puh i am having trouble figuring this PR out. reading the code it clearly was intended to be able to load history in batches of SLICE_SIZE.

I think we should make that work properly instead of hardcoding 0..SLICE_SIZE and calling it a day. this will effectively also remove code that was trying to make this a dynamic solution already.

making the batch size smaller (maybe even dynamic depending on terminal size and visible rows) has its merits and would allow fetching more data as needed and improving UX here too

[cruessler]

Since I wrote the initial code in file_revlog.rs, I can add a bit of context. :-) I copied the batching from revlog.rs, but I decided to use tui’s Table for rendering instead of CommitList (the latter is what Revlog uses). At that time, I was not aware that this would cause issues with batching.

From what I can tell, ratatui/ratatui#12 would resolve the issue because it would give us access to self.table_state’s offset property which we need to adjust, but currently can’t.

[extrawurst]

Ok I will merge this then. Let’s create a followup ticket to not forget about this Limitation and link it to the above ratatui issue 💪