Multi line review comments like github

[a1012112796]

Description

As title, I think it's usefull for code review. thanks.
It's also usefull for #10007

example in gh:

...

TODO List:

• Add start_line and end_line to API param (add multi-line comment support in api #25523)
• How to show Multiple lines code comment in comment list view? (add multi-line comment support in api #25523)
• Multiple lines choose in ui

[silverwind]

Also works using click on first line + shift-click on last line, it's what I use.

[socketwench]

This would be very useful to me too.

[generalludd]

Same here!

[delvh]

As #21150, which I found originally is now closed, here are my thoughts again:

I've already gathered some implementation thoughts on this as I think GitHub's approach has some major drawbacks:
At the moment, we only gather one number +/-$line for a review comment, where + means on new and - means on old diff, and $line is the line number.

My proposal is to limit multi-line comments to one side: Either you mark multiple lines on the old side, or multiple lines on the new side, but no mixture in between.
Reasoning: You very rarely want a multi-line message that has both old and new content (speaking from my experience as a "serial reviewer"), and it has a couple of benefits:

• it is (at least for the backend) far easier to implement: Simply store another signed number meant as a relative counter:
  • Case 1 - |x| = 0: It's a single-line message, so use the current algorithm including the corresponding settings.
  • Case 2 - |x| = 1: Show only the selected line without the additional context lines. Can be useful from time to time to clarify exactly which line you're talking about, and GitHub doesn't offer this functionality. Should be the same case as case 3, but is listed here for completeness.
  • Case 3 - |x| > 1: Show the next/last x lines, depending on the sign of x. Only show exactly the requested lines, and nothing more or less.
  • it might even make sense to switch the behavior of case 1 with the one of case 2 if an edge case can be avoided that way
• it is far less error-prone (see i.e. GitHubs problems with suggestions)
• the (backend) implementation is straightforward, hence much easier to maintain
• it is a much better user experience (I always have to hope that GitHub interprets my dragging correctly which it often just… doesn't)

[hiifong]

Maybe we can refer to gitlab's multi line review comments：https://github.com/gitlabhq/gitlabhq/blob/897fe87f08c8819ba6b7baa8024c8141acf290f5/app/assets/javascripts/diffs/components/diff_view.vue

[silverwind]

On a sidenote, I like how these vue files are ordered with <script> first, we should adopt that.