-
-
Notifications
You must be signed in to change notification settings - Fork 58
Refactor show hunk to avoid circular dependency #227
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
Conversation
|
Hi! Could you describe the circularity the description is referring to? ATM, I think, the direction is one-way between the show-hunk and the inline-popup subpackages. Have you considered options that would avoid renaming the moved options like I think you probably have a point here, but I'd rather avoid spending time guessing the reasoning. (The linked PR gives a hint, but still.) |
|
Ignore the renames, it's not important other than consistency. Basically, I need to refer to |
Why not just It seemed cleaner to me to have Keeping that property while adding For that matter, |
I don't know man, the problem with "incubation" is, there's never a well-defined end goal and the code can just deteriorate for no reason other than a catch-all "we are incubating". Like, how long do you want to incubate this? While the
I don't understand what you said. Why is it more "involved" ?
What's wrong with keeping every file in this repo? Just keep them organized. |
Eh, as long as it "feels" like a separate package wanting to get out. But the other reason (I thought I mentioned, but apparently not), is Git tooling does not deal with moving code between files too well, especially when renaming is added to the picture. And we'll have to do something with the renamed defcustoms, etc. It's a pain. Neither is a strong argument on its own, but argument for the move doesn't look too strong either.
I was referring to the scheme where the
Yes, like I said it's okay as a temporary solution (of the "nothing is more permanent" category).
Nothing's wrong, it's a solid option, just that if somebody else will want to take that package on and give it more attention, they might want to develop it in their own repository. Or not. |
19195b8 to
5e475e2
Compare
It didn't "feel" like a separate package wanting to get out. It felt like abandoned code rotting in limbo, this PR actually turns inline into what "feels" like a separate package.
That's not a problem with Git tooling, it's a problem with the old and crusty VC mode that fundamentally still operates at the file level as if we are still dealing with RCS and CVS, both of which do not preserve history unless you hack around it. It's high time you abandon that model and rearchitect VC. Anyway, I've just broken up the commit into a series preserving the file rename information. If there's any more hesitation, I'd appreciate if you lay them all out into a series of steps acceptable to you. |
12aa35d to
305eb61
Compare
|
@dgutov any idea on how to move this forward? |
93087d6 to
7bf4be7
Compare
3aae649 to
6bda678
Compare
|
I've broken down this PR into smaller commits, hopefully this is easier to review. |
90e27f9 to
75a8587
Compare
75a8587 to
7c57e8c
Compare
|
@wyuenho Thanks for the patience, having the changes split into separate commits indeed made it more transparent. |
|
This results in a lot of new warnings: |
|
@tarsius Thanks! Fixed them all, hopefully. Guess a byte-compilation check is due in the CI script. |
Please merge #257 first.
The diff is https://github.com/wyuenho/diff-hl/compare/fix-256...wyuenho:diff-hl:refactor-show-hunk
This is in preparation of an upcoming PR I want to make that will affect both
diff-hl-show-hunk-posframeanddiff-hl-show-hunk-inline.This is just a file rename, renamed the prefix from
diff-hl-inline-popuptodiff-hl-show-hunk-inline, removed an import fromdiff-hl-show-hunk, moved 2 defcustoms todiff-hl-inline-popupand added the appropriate aliases.