-
Notifications
You must be signed in to change notification settings - Fork 162
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
Modularization of the main struct #134
Conversation
- clock - vi stuff - requirement to do full repaint state management
f0775f0
to
371d7d2
Compare
src/engine.rs
Outdated
struct PromptWidget { | ||
prompt: Box<dyn Prompt>, | ||
offset: (u16, u16), | ||
origin: (u16, u16), | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not so sure about this, the idea was similar to the previous change (pulling out the terminal size). Maybe eventually all these can be clubbed into a struct like UiState and all we do is update it.
If we embrace immutability then we can just have a previous state and present state and then the painter just does a diff and figures out what to do. This way all its (painter) operations become decoupled. (Kinda like what elm, iced, react do). If this sounds something I can do a bit more research and draft a proposal for it.
src/engine.rs
Outdated
Enter, | ||
Mouse, // Fill in details later | ||
Resize(u16, u16), | ||
EditInsert(EditCommand), // HACK: Special handling for insert |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned it's a simple hack for now, I would not like a special case for InsertCommand
src/engine.rs
Outdated
CtrlD, // Don't know a better name for this | ||
CtrlC, // Don't know a better name for this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me know what the names for these operations are.
src/engine.rs
Outdated
trait InputParser { | ||
fn parse_event(&self, event: Event) -> ReedlineEvent; | ||
fn update_keybindings(&mut self, keybindings: Keybindings); | ||
fn edit_mode(&self) -> EditMode; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a makeshift interface for now. It should remain the same in spirit only (i.e. it parses Event
s to ReedlineEvent
s) but the interface will definitely need updating.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: Now the user of this lib can develop their own InputParser's without any help from the lib. All they need to do is adhere to this interface and we will be done. (prompt handling might pose a caveat in this though)
src/engine.rs
Outdated
let editor_event = match event { | ||
Event::Key(KeyEvent { code, modifiers }) => match (modifiers, code) { | ||
(KeyModifiers::NONE, KeyCode::Tab) => ReedlineEvent::HandleTab, | ||
(KeyModifiers::CONTROL, KeyCode::Char('d')) => ReedlineEvent::CtrlD, | ||
(KeyModifiers::CONTROL, KeyCode::Char('c')) => ReedlineEvent::CtrlC, | ||
(KeyModifiers::CONTROL, KeyCode::Char('l')) => ReedlineEvent::ClearScreen, | ||
(KeyModifiers::NONE, KeyCode::Char(c)) | ||
| (KeyModifiers::SHIFT, KeyCode::Char(c)) => { | ||
ReedlineEvent::EditInsert(EditCommand::InsertChar(c)) | ||
} | ||
(KeyModifiers::NONE, KeyCode::Enter) => ReedlineEvent::Enter, | ||
_ => { | ||
if let Some(binding) = self.find_keybinding(modifiers, code) { | ||
ReedlineEvent::Edit(binding) | ||
} else { | ||
ReedlineEvent::Edit(vec![]) | ||
} | ||
} | ||
}, | ||
|
||
Event::Mouse(_) => ReedlineEvent::Mouse, | ||
Event::Resize(width, height) => ReedlineEvent::Resize(width, height), | ||
}; | ||
|
||
Ok(editor_event) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And finally, we achieve complete segregation of even parsing into a separate struct.
- Rename: input_parsing to edit_mode - Rename: EmacsInputParser to Emacs - Rename: ViInputParser to Vi - Rename: InputParser to EditMode - Add docs: EditMode - Add docs: Vi - Add docs: Emacs
Next Steps: Resolve hacksIn order to achieve this segregation, I took a few shortcuts that need resolution
These hacks don't have any impact on end-user. Have a little bit of impact on code quality but is easily resolvable, once we have an agreed-upon solution. Pull non-editor commands out of
|
@sherubthakur - did you want to do those next steps in this PR or a follow-up? If you want to do them in a follow-up I can review this one with those remaining items in mind. |
I would suggest reviewing this assuming that I will do a follow-up PR (on both items)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good - just had some nits about constructor return types
Looks good |
This is like a 2nd take at the ambitious ticket #61 which was opend way back. But this time the results are more close to what we (me, @jntrnr and @sholderbach ) had in mind. (Note: Well what I inferred what @jntrnr and @sholderbach meant).
High level summary
Potential benefits
Todo
Note to reviewers
I think the best way to review this pull request is
src/engine.rs
and see if all the changes it's the internal structure and how it interacts with the new interfaces, a reasonable position to be in.I will try to add helpful comments on places where most attention is required.
Note: This is a massive PR, it would be completely understandable if you feel like it does not align with the project vision or if there is a possibility it can be broken down into smaller ones. I have opened this to get opinions from the maintainers.