Three features I'd want before using it:
1) Rather than triggering Sedy immediately on a reviewer comment, I'd like the trigger to be the original requester reacting to the comment with a thumbs-up. The requester knows what they're trying to say, and they should decide if the changes get made.
2) I wish there were an option to restrict it to comments for supported languages. Your examples are just changing markdown (not code), and I think rightfully so — I can easily see this tool becoming a way for a senior dev reviewer to attempt to avoid the back-and-forth with a junior dev by just posting some complex code substitutions... substitutions which could easily screw things up.
3) sed replacement actually seems too powerful for this job. For instance, if I want to make a replacement like:
s/**bold** thing/**bold thing**/
My point was orthogonal, though. I don't want a reviewer directly making committed changes to my code, period. Giving me control isn't about preventing inadvertent calls to sedy. It's about handling when someone suggests a substitution that I don't agree with, or want to reword.
My mindset might be different from what Marmelab intends, but to me, code review is a conversation about the changes I'm responsible for making, not a google doc where anyone can change the content I'm about to push.
$ echo http://foobar.com/mai/path/meme.png | sed 's@/mai/path@/sweet/new/path@'
For third point: it is actually the case! We have not implemented all the features of sed for this reason.
I keep the two first points to my list of requested features, it's very interesting!
For those simple types of changes, I like to amend the original commit, rather than make a new one. Of course, I come from using `git send-email` to send patches to a mailing list, where you are expected to send "[PATCH v2]" after you get feedback.
Using `s/foo/bar/f` for a `git commit --fixup` of the last commit who modify this change (only if part of the current PR)
I will not use this, but I can say this is an amazing piece of hackership.
Any particular reason to not use it? Just to know if we can improve something.
We'll fine-tune that behavior with the feedback we'll have.
-- old text
++ new text
Github will highlight that as a diff.
Maybe doing the reverse, if a change is made through inline edit automatically add a comment with the specific change made.
I just can foresee undesired consequences. Someone not escaping their sed correctly (I.e. they try to replace a string with a slash or apostrophe)
All of that is explained on the article.
I feel like other sed expressions might be even more useful in this format. For example:
200i #TODO optimize this
The project is still young and we'll implement in priority what save time to developers.