-
Notifications
You must be signed in to change notification settings - Fork 444
Fix panicking when diffing filenames with space enclosed dashes #173
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
406a716
to
f709c2c
Compare
Hi @pt2121 thanks very much for this! Did you see #120 where we are trying to handle the Some example input is (
|
Yes, sure. Thanks for the pointer. I'll look into it. |
Thanks! |
* Fix panicking when diffing filenames with space enclosed dashes (dandavison#139). * Handle the diff.noprefix flag.
Hi @dandavison, |
Test get_file_extension_from_file_meta_line_file_path
assert_eq!( | ||
get_file_extension_from_file_meta_line_file_path("Makefile"), | ||
Some("Makefile") | ||
); |
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.
Before I write anything else I want to make it clear that you've already done more than enough for your PR to be merged and it's very helpful, so thank you!
I don't have time right now to do further work on these edge cases myself so I'm just going to make some additional comments on the off chance that you want to double-check my thinking, since it's very helpful to have someone else familiar with this code.
Would you agree that this test case demonstrates a bug? I wonder if what we should do (in a different PR) is determine (programatically?) the cases where the sublime syntax definition is keyed off the entire filename (like Makefile
, Dockerfile
) and otherwise refuse to identify a file extension for random filenames that do not look like *.foo
.
diff --git a/src/parse.rs b/src/parse.rs
index e1a0860..78cea85 100644
--- a/src/parse.rs
+++ b/src/parse.rs
@@ -123,6 +123,11 @@ mod tests {
get_file_extension_from_file_meta_line_file_path("Makefile"),
Some("Makefile")
);
+ // TODO: The fact that the following test passes is perhaps a bug.
+ assert_eq!(
+ get_file_extension_from_file_meta_line_file_path("rs"),
+ Some("rs")
+ );
assert_eq!(
get_file_extension_from_file_meta_line_file_path("a/src/Makefile"),
Some("Makefile")
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.
Oh, I see. Nice catch.
I'm not sure if there is a good way to differentiate them unless we have a list of all file types that don't have an extension e.g. Makefile
, Dockerfile
.
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.
get_file_extension_from_diff_line("diff --git a/src/main.rs b/src/main.rs"), | ||
get_file_extension_from_marker_line( | ||
"--- src/one.rs 2019-11-20 06:47:56.000000000 +0100" | ||
), |
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.
So I believe that there's another bug remaining (not your fault or responsibility!), in that unified diff is still broken for file names with spaces:
--- "src/pa r se.rs" 2020-05-03 16:40:13.851935846 -0400
+++ "src/pa rse.rs" 2020-05-03 16:41:49.798457052 -0400
@@ -231,4 +231,7 @@
);
}
}
-vjhvjj
+
+pub fn test(s: &str) {
+ println!("hello {}", s);
+}
![]() |
If I remove the double quotes and spaces from those filenames, then delta syntax-highlights the added function as Rust:
--- src/parse.rs 2020-05-03 16:40:13.851935846 -0400
+++ src/parse.rs 2020-05-03 16:41:49.798457052 -0400
@@ -231,4 +231,7 @@
);
}
}
-vjhvjj
+
+pub fn test(s: &str) {
+ println!("hello {}", s);
+}
![]() |
Thanks a lot for this work. I'll do a final review/test and merge soon. |
Have you had a chance to look at this? Anything else I should address in this PR? |
No, it looks great, thanks very much! |
No problem. I will try fixing the remaining bug when having time. |
Fixes #139