-
Notifications
You must be signed in to change notification settings - Fork 393
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
diffedit: start the builtin ui with all boxes checked #5393
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -44,6 +44,7 @@ use thiserror::Error; | |
use self::builtin::edit_diff_builtin; | ||
use self::builtin::edit_merge_builtin; | ||
use self::builtin::BuiltinToolError; | ||
pub use self::builtin::InitialSelection; | ||
pub(crate) use self::diff_working_copies::new_utf8_temp_dir; | ||
use self::diff_working_copies::DiffCheckoutError; | ||
use self::external::edit_diff_external; | ||
|
@@ -255,14 +256,17 @@ impl DiffEditor { | |
right_tree: &MergedTree, | ||
matcher: &dyn Matcher, | ||
format_instructions: impl FnOnce() -> String, | ||
initial_selection: InitialSelection, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe better to always open builtin editor with everything checked? It's weird that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't have a strong opinion myself, but the per-command difference was discussed here: #5390 (comment) It seems to make sense to me that we would want e.g. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think there's a way of telling external 2-way diff editors that. But we can tell external 3-way diff editors that by setting the middle state to be either the same as the left (for By the way, another aspect is what the effect of starting the diff editor and immediately quitting should do. One could argue that it should have the same effect as not even starting it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Good point. I slightly prefer that There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I haven't used external diff tools, so trying meld and meld-3 just now, they apparently start with everything selected (whereas the builtin ui starts with nothing selected). On the face of it, the inconsistency is a bit weird. As Martin says, for 3-way diff editors, you could change this by choosing the middle file. For 2-way diff editors, you could change the default by swapping left and right, although that'd possibly be too confusing to use. If we make the diff tools consistent, the most disrupting change would probably be No clear conclusion. |
||
) -> Result<MergedTreeId, DiffEditError> { | ||
match &self.tool { | ||
MergeTool::Builtin => { | ||
Ok( | ||
edit_diff_builtin(left_tree, right_tree, matcher, self.conflict_marker_style) | ||
.map_err(Box::new)?, | ||
) | ||
} | ||
MergeTool::Builtin => Ok(edit_diff_builtin( | ||
left_tree, | ||
right_tree, | ||
matcher, | ||
self.conflict_marker_style, | ||
initial_selection, | ||
) | ||
.map_err(Box::new)?), | ||
MergeTool::External(editor) => { | ||
let instructions = self.use_instructions.then(format_instructions); | ||
edit_diff_external( | ||
|
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.
comment (non-blocking): We could consider if we want to bundle the "configuration" kind of arguments here into a single
struct
for organizational reasons, but I don't feel strongly.