Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add syntax highlighting for blame view (#745) #1914

Merged
merged 1 commit into from
Feb 19, 2024

Conversation

tdtrung17693
Copy link
Contributor

@tdtrung17693 tdtrung17693 commented Oct 3, 2023

This Pull Request fixes/closes #745.

It changes the following:

  • Add syntax highlighting for blame view

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

@tdtrung17693
Copy link
Contributor Author

Hi @extrawurst, could you take a look into this PR? If there is anything need to change please let me know. Thank you!

src/app.rs Outdated Show resolved Hide resolved
struct SyntaxFileBlame {
///
pub commit_id: CommitId,
///
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why some empty comments and some without? consistency please

src/components/blame_file.rs Outdated Show resolved Hide resolved
@@ -295,6 +315,10 @@ impl BlameFileComponent {
table_state: std::cell::Cell::new(TableState::default()),
key_config,
current_height: std::cell::Cell::new(0),
async_highlighting: AsyncSingleJob::new(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i would argue we should put it in an option and only keep it around while there is an async job ongoing and initialize it to None first

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I see in the codebase, this is currently the way that other components instantiate the async jobs. Also, keeping this way makes it easier to process the job's result, instead of multi-level pattern-matching.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in order to keep things maintainable i started using this pattern successfully in Revlog with LogSearch.
in our case here we can combine probably 4 member (async_blame, syntax_progress, file_blame and async_highlighting) variables into an enum depending on our state and it makes it easier to reason which ones are expected to be valid at what state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Let me try it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the status here? Would be great to carry over the finish line!

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will put it in draft till reworked

Copy link
Contributor Author

@tdtrung17693 tdtrung17693 Jan 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I refactored it and combined all those 4 processes into the one below just as you suggested.

enum BlameProcess {
GettingBlame(AsyncBlame),
SyntaxHighlighting {
unstyled_file_blame: SyntaxFileBlame,
job: AsyncSingleJob<AsyncSyntaxJob>,
},
Result(SyntaxFileBlame),
}

pub struct BlameFileComponent {
title: String,
theme: SharedTheme,
queue: Queue,
visible: bool,
open_request: Option<BlameFileOpen>,
params: Option<BlameParams>,
table_state: std::cell::Cell<TableState>,
key_config: SharedKeyConfig,
current_height: std::cell::Cell<usize>,
blame: BlameProcess,
app_sender: Sender<AsyncAppNotification>,
}

match progress {
SyntaxHighlightProgress::Progress => {
self.syntax_progress =
self.async_highlighting.progress();
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have to double check but i think the progress retrieval is pretty lightweight, no need to cache it

file_blame.styled_text =
Some(syntax);
}
// *(self.file_blame.s = Either::Left(syntax);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please clean up not needed comments

self.file_blame
.as_ref()
.map_or_else(Vec::new, |file_blame| {
file_blame
return file_blame
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please keep it consistent with the non-return call style, last statement without ; is the return value

text.clone(),
params.file_path.clone(),
));
self.async_highlighting.spawn(AsyncSyntaxJob::new(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why spawn the same job twice?


static NO_COMMIT_ID: &str = "0000000";
static NO_AUTHOR: &str = "<no author>";
static MIN_AUTHOR_WIDTH: usize = 3;
static MAX_AUTHOR_WIDTH: usize = 20;

struct SyntaxFileBlame {
pub commit_id: CommitId,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these elements (commit_id, path and lines) are FileBlame please reuse that component

@@ -295,6 +315,10 @@ impl BlameFileComponent {
table_state: std::cell::Cell::new(TableState::default()),
key_config,
current_height: std::cell::Cell::new(0),
async_highlighting: AsyncSingleJob::new(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in order to keep things maintainable i started using this pattern successfully in Revlog with LogSearch.
in our case here we can combine probably 4 member (async_blame, syntax_progress, file_blame and async_highlighting) variables into an enum depending on our state and it makes it easier to reason which ones are expected to be valid at what state.

@extrawurst extrawurst added this to the v0.25 milestone Dec 20, 2023
@extrawurst extrawurst marked this pull request as draft December 25, 2023 20:47
Copy link
Owner

@extrawurst extrawurst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update

Copy link
Owner

@extrawurst extrawurst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks much better. please update to current master and then we can merge

@extrawurst extrawurst removed this from the v0.25 milestone Feb 19, 2024
@extrawurst extrawurst merged commit af9da95 into extrawurst:master Feb 19, 2024
17 of 18 checks passed
@extrawurst
Copy link
Owner

@tdtrung17693 thank you so much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

use syntax highlighter in blame view
2 participants