Crashing somewhere here at the moment:

ERROR: index outside of buffer: the area is Rect { x: 0, y: 0, width: 213, height: 49 } but index is (0, 49)

Reading errors is really tricky currently, maybe I should implement a panic hook that logs the stacktrace to a file somewhere in a separate PR. What do you think about that @altsem ?

I've been hacking away some more and the current problem is rendering HunkLines.
In master we construct each display when the HunkLine is created after highlight::highlight_hunk_lines has done its thing.

We have since moved over highlighting to the render step but the problem is now that we need to rework src/highlight.rs to support line by line highlighting. This is so that we only have to highlight, style and render the hunk lines that are visible instead of the entire diff.

I skimmed through src/highlight.rs a little to see what could be done but I haven't come up with anything yet.

HunkLines are currently rendered unhighlighted.

@mWalrus,

Panic hook

I realize this used to exist, seems I dropped it (by mistake?) in 3cb28c6.
But yea that sounds like a good idea. I hope that would give nice context from this error though. A lot of errors are handled explicitly via a Res, and they lose some context in this manner.

Highlighting

It does become tricky to highlight just a single line, since the highlighting is contextual. Now, it has some limited context actually -just a single hunk at a time.
Gitu used to syntax-highlight the entire file in a previous version even.

My idea was that if there was some way to cache/memoize highlighted lines, the code constructing the screen could just be asking

• "Give me a line 3 of hunk 1, highlighted".
• "Give me a line 4 of hunk 1, highlighted".
• etc..

Now some caching/memoizing middle layer could then check if it has hunk 1 in store. And then either:

• Highlight hunk 1, store it and return the line
• Read hunk 1 from store and return the line

But in practice, using something like https://github.com/jaemk/cached could be neat:

#[cached]
pub(crate) fn highlight_hunk<'a>(
    config: &'a Config,
    diff: &'a Rc<Diff>,
    file_i: usize,
    hunk_i: usize,
) -> HunkHighlights {

struct HunkHighlights {
    spans: Vec<(Range<usize>, Style)>,
    line_index: Vec<usize, Range<usize>>,
}

impl HunkHighlights {
    fn get_line_spans(&self, line: usize) -> &[(Range<usize>, Style)] {
        let line_range = self.line_index[line];
        spans[line_range]
    }
}

Consider these some suggestions.

@altsem,

Syntax highlighting

Had never heard of cached before but it looked pretty fitting so I tried my hand at implementing some caching for syntax highlighting and it seems to be working! I'm currently failing a bunch of tests but most of the original functionality seems to be restored. Will take a closer look at tests next.

One thing I've also noticed is that even if we don't highlight the diffs immediately anymore, we parse and prepare diffs for highlighting even if they are not being rendered on the screen. Not sure if this means that they'll get processed for syntax highlighting anyways because of how Items are being taken care of when drawing a frame but I fear that this might be the case.

Panic hook

I've moved discussion to #393 :)

@mWalrus i made some hashes for other purposes the other day here :) https://github.com/altsem/gitu/blob/master/src/items.rs#L126

It's needed to populate Item.id.
Which is used to identify collapsed/expanded sections.

Perhaps there's a way to compute it just once? Else it might not be too expensive to call again

@mWalrus i made some hashes for other purposes the other day here :) https://github.com/altsem/gitu/blob/master/src/items.rs#L126

It's needed to populate Item.id. Which is used to identify collapsed/expanded sections.

Perhaps there's a way to compute it just once? Else it might not be too expensive to call again

@altsem,
Ohh, yeah okay, that's cool! We should use those then. I can just take Item.id as a parameter for ItemData::to_line which would mean we won't have to compute anything more than we were already doing before!

Oh, and, I reviewed everything and think we're basically good to go with the aforementioned things fixed!

The changelog generation is currently based on git commits, but I'm considering trashing it and doing it manually at some point...
https://github.com/altsem/gitu/blob/master/docs/dev-tooling.md

Or if we squash everything in here. 🤔

> git cliff --unreleased
# Changelog

All notable changes to this project will be documented in this file.

## [unreleased]

### 🚀 Features

- Cache syntax highlighting for hunks
- `ItemData::to_line` -> `ItemData::to_lines`
- Implement commit rendering
- JIT rendering
- Ability to rename a remote
- Switch terminal backend from Crossterm to Termwiz

### 🐛 Bug Fixes

- Don't format!() hunk highlight cache-keys
- Use already computed hunk hash for caching
- Return commits from `selected_rev` again
- Restore ref styling
- Replace tab-characters with 4 spaces again
- Generate more collision resistant cache-key
- Restore stash item styling
- `Diff::hunk_content` to unify getting hunk content
- Restore creation of `RefKind::Remote` items
- Store visual reference prefix to apply later
- Unify hunk line range scanning into one fn
- Typo in stash string
- Restore status section headers
- Restore commit view header
- `ItemData::Raw` holds an owned String
- `ItemData::to_line` now produces a single line
- (mostly) restore hunk line rendering
- Correctly highlight hunks again
- Removing very hacky logging that made it thru
- Make `Item.data` is no longer optional
- Adding some missing section headers
- Construct lines again
- Restore replace of TAB with 4 spaces
- Typo in branch status text

### ⚡ Performance

- Avoid some allocations
- More efficiently keep track of changes between updates

<!-- generated by git-cliff -->

@altsem,
We can squash the commits to make it easier. We can reword it so it makes more sense as well! 😊

I'll merge this, let it sit in master for a few days, perhaps bundle some more stuff in, then include it in a release soon :) gj!

This is a great improvement, I recently had a case where highlighting (a brutal JSON file) caused a lot of slowdown, so thanks!

The changelog generation is currently based on git commits, but I'm considering trashing it and doing it manually at some point... https://github.com/altsem/gitu/blob/master/docs/dev-tooling.md

Or if we squash everything in here. 🤔

I noticed this, and thought I'd point out that you could configure git-cliff to filter based on merge commit, so if you discard non-merge commits then as long as your merge commit is conventional, it would be a "one PR equals one changelog item" workflow.