Skip to content

Log Margin #654

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

Closed
wants to merge 7 commits into from
Closed

Conversation

PriceHiller
Copy link

This PR tracks integrating the log margin from Magit into Neogit.

This is being set as a draft so the modifications and any progress made can be seen instead of a PR coming out of the backrooms with a bajillion commits.

@PriceHiller
Copy link
Author

As a heads up I may be bit slow over the next few days on this PR and other PRs/issues. Key word being may. I have a few things I have to get done over the next week-ish and I'm not sure as to the effort involved, so feel free to take over here.

@CKolkey
Copy link
Member

CKolkey commented Jul 21, 2023

No worries - my brother is visiting and I need to drain/clean all my radiators so... I don't have loads of free time either ;)

@CKolkey
Copy link
Member

CKolkey commented Jul 22, 2023

So, started looking into this one since I had a feeling it would be weird. Here's my thoughts:

  • All the options need to be configs because the values need to be read in a non-action context. The option values only exist for the callback, and these values need to be available at all times. OR:
  • Read the state values. But if a user has this disabled then we're hosed, so I think the first idea is better
  • I think the config's can have a callback which updates the status buffer without closing the popup
  • I think we need to add a way to have a suffix on the config options, to add "order" to the end of the order select
  • config elements should take a display key in the options that hides the underlying config value.
  • We can use neogit.status.<xxx> to have a private namespace for git config values
  • Probably other things but thats all for now

@PriceHiller
Copy link
Author

Alright, come this weekend I'm grinding on this. To be perfectly honest I haven't played around at all with the Neogit UI lib, so it may (see, probably) take me longer to kick this out the door than you.

The one thing I have already thought of, that may or may not be an issue, is updating the status components in place considering that I don't think we track line positions for elements within the Status buffer. I may be wrong on that one, I haven't checked yet. I know there is the status _refresh function, but I'm not certain that's the best solution.

Regardless, I am going to get to working on this come Saturday and Sunday and fuck around and find out then.

@CKolkey
Copy link
Member

CKolkey commented Jul 29, 2023

Alright, come this weekend I'm grinding on this. To be perfectly honest I haven't played around at all with the Neogit UI lib, so it may (see, probably) take me longer to kick this out the door than you.

Don't sweat it, just a matter of time. Ask all the questions ;)

The one thing I have already thought of, that may or may not be an issue, is updating the status components in place considering that I don't think we track line positions for elements within the Status buffer. I may be wrong on that one, I haven't checked yet. I know there is the status _refresh function, but I'm not certain that's the best solution.

Yea, so, the status buffer is the only buffer that doesn't use the "new" library. Theres an "at some point" task to rewrite it using the same lib as everything else, but it's like... 1000+ lines long, so it's not going to happen overnight. So, unlike the popups and commit/reflog/log views, the status buffer doesn't have components. It's just a line-buffer with syntax. So, to update the status buffer, you just redraw it. You can see that behaviour with how folds (sections) get toggled opened/closed.

@PriceHiller
Copy link
Author

Yea, so, the status buffer is the only buffer that doesn't use the "new" library. Theres an "at some point" task to rewrite it using the same lib as everything else, but it's like... 1000+ lines long, so it's not going to happen overnight. So, unlike the popups and commit/reflog/log views, the status buffer doesn't have components. It's just a line-buffer with syntax. So, to update the status buffer, you just redraw it. You can see that behaviour with how folds (sections) get toggled opened/closed.

So I guess I can use the UI lib's row and column then wrap that in a custom render_section for the UI lib stuff as a in place hack for now. Later on it should all get refactored out to the UI lib.

@CKolkey
Copy link
Member

CKolkey commented Jul 29, 2023

IMO, I'd first get all the config and data pushed to the line buffer and we can make it look fancy after.

@PriceHiller
Copy link
Author

Ok, so I have been looking at this for 30 mins.

I am going to implement a hack and abuse status.refresh functions for now.

In the future, I want to do a total rewrite of how the Status Buffer is managed which will make the hack I am going to go with obsolete.

@CKolkey
Copy link
Member

CKolkey commented Jul 30, 2023

#614 Does a bit of that wrt. repo-state, just fyi. Curious to see what you have in mind :)

@PriceHiller
Copy link
Author

Hey I realized this has been left open by me.

At this time I don't think I'm in a position where I am going to get this done or worked on in a reasonable period. Sorry about that.

I'm going to go ahead and close this out. Neogit kicks ass, you folks (@CKolkey & @ten3roberts) have done a helluva lot of work to it, quite impressive where it is now.

@CKolkey
Copy link
Member

CKolkey commented Sep 11, 2023

All good dude, thanks for all the contributions and maybe we'll see you some time down the road :)

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.

2 participants