Visual selection isn't captured if it starts from the bottom

[Igor Lacerda]

Issue Description

Type: bug report

Describe what happened (or what feature you want)

Visual selection isn't captured in a review, if the selection starts from the bottom

Describe what you expected to happen

The visual selection should be "captured"

How to reproduce it (as minimally and precisely as possible)

1. Start a review
2. Start visual mode (linewise) and select a couple of lines upwards
3. Try to add a comment / suggestion. The selection will appear empty.

Tell us your environment

To be fair, I don't think there's anything in my environment that would cause this behavior, but I'm surprised no one else has reported yet.

Anything else we need to know?

[HampusMat]

I'm able to reproduce this.

[HampusMat]

I was able to fix this by inverting the comment start and end lines before writing the thread snippet if the start line is after the end line.

--- a/lua/octo/ui/writers.lua
+++ b/lua/octo/ui/writers.lua
@@ -711,6 +711,10 @@ function M.write_thread_snippet(bufnr, diffhunk, start_line, comment_start, comm
   -- we need to use the original positions for comment_start and comment_end
   -- since the diff hunk always use the original positions.
 
+  if comment_start > comment_end then
+         comment_start, comment_end = comment_end, comment_start
+  end
+
   start_line = start_line or vim.api.nvim_buf_line_count(bufnr) + 1

However, it is not always that all selected lines are included. I could try to find a solution for this but i currently don't the energy to try to parse through this gigantic function. There's a reason for the practice of keeping functions under 100 lines long.

[Igor Lacerda]

Hey, thanks for taking a look! Is there any way I could help?

[Alvaro Muñoz]

Agreed, that function could definitely be improved. Any refactors are welcome!

[HampusMat]

Hey, thanks for taking a look! Is there any way I could help?

You could possibly help refactoring this function. It is definetly needed