reverse the dependency between helix-tui and helix-view #366
Conversation
|
Note: this probably conflicts #345. Could you maybe copy over the changes from there so we subsume that PR? I think this is a pretty good idea. It initially wasn't possible because we depended on |
|
Yes I will copy the changes from #345 over to this PR sometime tomorrow as its late today. |
|
No rush :) |
Kethku
force-pushed
the
dev/kethku/remove-tui-dependency-from-helix-view
branch
from
76806e0
to
3e0b7fe
Compare
|
Rebased on the merged keybinding PR. Also fixed a bunch of tests. This is ready for review |
|
I had to pull the KeyCode and KeyModifiers types out of crossterm to be compatible with the previous PR. I did the same thing I did with the tui types and added from and into implementations to go back and forth between the originals. |
| default = [] | ||
| term = ["crossterm"] |
…#366) * reverse the dependency between helix-tui and helix-view by moving a fiew types to view * fix tests * clippy and format fixes Co-authored-by: Keith Simmons <keithsim@microsoft.com>
Does step one of #39 (comment)
"helix-view needs to be refactored to have it's own generic key/style/color structs. Fix previous broken refactor key into helix-view #345 is a start but it depends on crossterm. Using generic structs would let us drop the crossterm dependency from helix-view."
I did this by lifting CursorKind, Margin, Rect, Color, Modifier, and Style into helix-view. I then reversed the dependency making helix-tui depend on helix-view rather than the other way around. I also made helix-view's dependency on crossterm optional in order to allow impl From<crossterm::style::Color> on the generic Color type.
Your comment suggested that the lifted types should be "generic". I think the types in the tui crate were pretty generic, but if you have ideas for how these should be modified to make them more "generic", I'd be happy to do it. I just didn't know what you were thinking.
Let me know if this is what you had in mind, it didn't take too long to do, and I'm looking to do these types of refactorings as a way to get to know the codebase better, so I'm not at all attached to this particular PR. Just trying to pitch in.