Skip to content
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

Add review comments to PR buffers #105

Merged
merged 27 commits into from
Mar 1, 2021
Merged

Add review comments to PR buffers #105

merged 27 commits into from
Mar 1, 2021

Conversation

pwntester
Copy link
Owner

@pwntester pwntester commented Feb 24, 2021

  • Show review comments in PR buffer
  • Group review threads by review
  • Show diff hunk
  • Add multi-level folding (review/thread/comment)
  • Improve hunk view to only show commented lines and 4 lines context
  • Prettify review thread header
  • Add line numbers to diff chunk
  • Indent comment headers
  • Differentiate regular comment metadata from review comment one
  • comment (un)resolve should work from PR buffer
  • Add review thread replies from PR buffer will need to use the REST v3 API
  • request issue comments and pullrequestreviews as timeline events
  • show basic timeline items
  • Add configuration setting to turn it on/off (on by default)

@pwntester
Copy link
Owner Author

@tami5 @weilbith the core functionality should be already working. I changed quite a few things so may have broke something elsewhere, still need to do more testing.

The UI stil need improvements though, any suggestions are welcome.

@pwntester pwntester marked this pull request as ready for review February 27, 2021 12:07
@pwntester pwntester self-assigned this Feb 27, 2021
Copy link
Contributor

@weilbith weilbith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is kind of a test review for this PR features. But I have the following issues which might not be related directly to it. When I now call Octo pr list I get the following error I did not before (but could also be a Telescope update:

Error executing vim.schedule lua callback: ...test_site/pack/packer/opt/octo.nvim/lua/octo/writers.lua:129: bad argument #1 to 'ipairs' (table expected, got nil)

EDIT:
The other issues is that if I hit <CR> while writing the final submit message I get an error (I can't see atm). And the second time I hit the key it just submitted it...

@weilbith
Copy link
Contributor

weilbith commented Feb 27, 2021

While I was hitting <space>ca to add this comment (for open an actual review conversation thread), I got this error:

E5108: Error executing lua ...test_site/pack/packer/opt/octo.nvim/lua/octo/reviews.lua:268: attempt to call field 'write_virtual_texxt' (a nil value)

And while I tried to paste this error message with "+p I got the error: clipboard error: -2. I pasted it now in insert mode with <C-S-v> by my terminal emulator.

And again while I try to safe this buffer to add a review comment I get the error: E382: Cannot write, 'buftype' open is set. The command echo &buftype returns nofile.


Obviously I was not able to add this comment via Octo. So I copied it and pasted it to the web-browser.

@pwntester
Copy link
Owner Author

This is kind of a test review for this PR features. But I have the following issues which might not be related directly to it. When I now call Octo pr list I get the following error I did not before (but could also be a Telescope update:

Just fixed it

The other issues is that if I hit while writing the final submit message I get an error (I can't see atm). And the second time I hit the key it just submitted it...

Are you using delimate or similar plugin?

/packer/opt/octo.nvim/lua/octo/reviews.lua:268: attempt to call field 'write_virtual_texxt' (a nil value)

Ups, that was a typo in a recent refactor, should be fixed now

And while I tried to paste this error message with "+p I got the error: clipboard error: -2. I pasted it now in insert mode with by my terminal emulator.

Not sure about this one, not sure is Octo related

And again while I try to safe this buffer to add a review comment I get the error: E382: Cannot write, 'buftype' open is set. The command echo &buftype returns nofile.

This could be caused by any of the previous errors. Please try again with latest fixes

Thanks!

@weilbith
Copy link
Contributor

weilbith commented Feb 27, 2021

Thanks for the fast response! 🙃

Are you using delimate or similar plugin?

Yes. In combination with nvim-compe (which is wrapping the <CR> mapping)


I'll check it again tomorrow. Or more precisely at daytime of today (for my timezone). ^^

Btw: would it be possible to set the filetype for the buffer to add a comment to markdown? Would be quite helpful.

@pwntester
Copy link
Owner Author

pwntester commented Feb 28, 2021

Btw: would it be possible to set the filetype for the buffer to add a comment to markdown? Would be quite helpful.

Sure, I implemented it

Yes. In combination with nvim-compe (which is wrapping the mapping)

I was able to reproduce the problem with the same combo. Using just compe w/o delimate does not create any issues though so the problem seems to be caused by delimate. Will take a look

EDIT: for now, I remapped in insert mode to to override any other mappings. This solves the problem but leaves you with no completion

Copy link
Contributor

@weilbith weilbith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some text for test purpose.

README.md Show resolved Hide resolved
README.md Show resolved Hide resolved
@weilbith
Copy link
Contributor

weilbith commented Feb 28, 2021

The indentation of the actual comment text in the thread is off because of these surrounding lines on the left site. If this gets correctly aligned it would look better.
octo_indent

@weilbith
Copy link
Contributor

Could you add some context lines around the commented line in a review thread? Maybe a configurable number of how many lines above and below the hunk (if multiple lines got selected).
Later in the pop-issue it would be great to see the code snippet in actual highlighting and other features of the actual file buffer (e.g. [type] hints, signatures, references, etc. pp).

@weilbith
Copy link
Contributor

And if I could color the text like THREAD, the date etc would be great. Atm it is too greyish white for me. I need to improve my markdown concealing and stuff, but its a bit hard to strongly differ between "UI" and user written content. Maybe event the lines that surround comments. Doesn't hurt to open the highlight groups if not already. Sorry if I just missed this group. 🙈

lua/octo/reviews.lua Outdated Show resolved Hide resolved
@weilbith
Copy link
Contributor

@pwntester sorry that I have so many comments. I love to play around with this feature. It is so great! 😊 🚀
This feature is so big, you might want to merge it and open issues/PRs as follow ups to tackle certain problems. Else this might take very long. 🙈

@pwntester
Copy link
Owner Author

The indentation of the actual comment text in the thread is off because of these surrounding lines on the left site. If this gets correctly aligned it would look better.

Not sure I understood what you mean. Those surrounding lines are the sign column, cannot change indentation.

@pwntester
Copy link
Owner Author

Could you add some context lines around the commented line in a review thread? Maybe a configurable number of how many lines above and below the hunk (if multiple lines got selected).

This is what the GitHub UI shows currently. I'm getting it from the diffhunk, so it would be limited to lines appearing in the hunk, otherwise I would need to make an additional call to the API to get the file contents.

@pwntester
Copy link
Owner Author

And if I could color the text like THREAD, the date etc would be great. Atm it is too greyish white for me. I need to improve my markdown concealing and stuff, but its a bit hard to strongly differ between "UI" and user written content. Maybe event the lines that surround comments. Doesn't hurt to open the highlight groups if not already. Sorry if I just missed this group. 🙈

That should be OctoNvimMissingDetails but I think I should make a new HL for it because that one was meant for a different thing and I just reused it so I just created OctoNvimTimelineItemHeading

Any ideas about how to differentiate the virtual text lines from the editable blocks?
Do you like the use of uppercase for THREAD, REVIEW, COMMENT, etc?

@pwntester
Copy link
Owner Author

@pwntester sorry that I have so many comments. I love to play around with this feature. It is so great! 😊 🚀
This feature is so big, you might want to merge it and open issues/PRs as follow ups to tackle certain problems. Else this might take very long. 🙈

Yep, I will use this branch this week at work to catch up more bugs and then merge it. I think its functional, just the UI is not as optimal as it should be. But its hard to get what I would like with just a text buffer. If only I could soft indent lines of the buffer 🙄

@weilbith
Copy link
Contributor

That should be OctoNvimMissingDetails but I think I should make a new HL for it because that one was meant for a different thing and I just reused it so I just created OctoNvimTimelineItemHeading

Ah nice. I'll use it. Let's see how I can beautify this for my setup.

Any ideas about how to differentiate the virtual text lines from the editable blocks?

Hmm. Good question. The only dumb thing that comes into my mind would be a highlighting that only affects the background color, which then subtle differs from the background. But despite aesthetic issues this suffers from the same issue as the treesitter-refactor context highlight as you could only highlight he background of the actual text, not a box around the text including "imaginary" whitespaces behind shorter lines.

Do you like the use of uppercase for THREAD, REVIEW, COMMENT, etc?

Yes I do. Perfectly nice from point of view. 👌

@weilbith
Copy link
Contributor

This is what the GitHub UI shows currently. I'm getting it from the diffhunk, so it would be limited to lines appearing in the hunk, otherwise I would need to make an additional call to the API to get the file contents.

Oh really. Hmm. If kinda differs in the web UI for me. But that's fine I guess and could be improved later.
The only other difference would be that GH UI does show old and new context compared to each other what is missing here. So as you don't have the split diff view here, you have a hard time to tell what the actual change was that took place here. 🤷

@weilbith
Copy link
Contributor

weilbith commented Feb 28, 2021

Not sure I understood what you mean. Those surrounding lines are the sign column, cannot change indentation.

Oh. Wait. I need to investigate there. Maybe the planned folding would improve this. 🤔
I need to check some things and setting options to "see" it better. But ofc it makes sense that this is not part of the actual buffer content. :face_palm:

@pwntester
Copy link
Owner Author

pwntester commented Mar 1, 2021

Recap:

Bugs:

  • when adding a new review comment the cursor goes to the QF window
  • off-by-one box-line issue on empty lines of commented lines hunks
  • horizontal split when commenting on the LEFT side?
  • escape double quotes on gh layer

Questions:

Also the content from the cite above was in the comment buffer initially.

What do you mean here? do you refer to the path [RIGHT|LEFT] (start, end) virtual text? should I remove it?

Hmm. Good question. The only dumb thing that comes into my mind would be a highlighting that only affects the background color, which then subtle differs from the background. But despite aesthetic issues this suffers from the same issue as the treesitter-refactor context highlight as you could only highlight he background of the actual text, not a box around the text including imaginary whitespaces behind shorter lines.

Just implemented this. It will apply OctoNvimEditable which defaults to a highlight with same background color as NormalFloat
I would prefer to soft wrap at the end to avoid hl to be applied to the whole line. Maybe we can do something like Goyo does and add a small padding vert split to the right

@weilbith
Copy link
Contributor

weilbith commented Mar 1, 2021

when adding a new review comment the cursor goes to the QF window
horizontal split when commenting on the LEFT side?

I think those are related as I have described here

when adding a suggestion use a filetype rather than suggestion so at editing time highlght is applied. then it can be swaped with suggestion before commiting so GH treats it as a suggestion

This PR is really packed so I already exported this into a new issue #108 You do so much in this PR. It should come to an end and cut of new features where possible. Sorry for all this stress. 🙈

add more context around the commented lines hunk and show both left/right versions for the commented lines range

Again I would split this into a new issue. The PR solution is totally fine for the moment. It can be improved later. This is not straight forward as the solution approach/goal is not clear. There are multiple opportunities for this issue. Do you agree? I would open the issue then. So it can be discussed there and tackled when ever someone has time and motiviation.

on PR/Thread buffers suggestions should show the diff and not just the new suggestion

Same as before. I think the PR solution is fine for the moment and it could be a new issue to improve.

What do you mean here? do you refer to the path [RIGHT|LEFT] (start, end) virtual text? should I remove it?

Yeah, sorry the cite was not visible because it was actual a virtual text where I put a real > cite initiator before. I left a comment here regarding this virtual text. Atm it is very confusing. I don't know your intention behind it. I the user forgot which line he wanted to comment he can cancel and start again. Or maybe provide a hint in the file name the user sees in his status line?

Just implemented this. It will apply OctoNvimEditable which defaults to a highlight with same background color as NormalFloat
I would prefer to soft wrap at the end to avoid hl to be applied to the whole line. Maybe we can do something like Goyo does and add a small padding vert split to the right

Amazing! 🤩
I have an open issue at the tressitter plugin. There they say it is not possible. How did you solve it. Could you leave a comment at nvim-treesitter/nvim-treesitter-refactor#12 ? But maybe your approach is not usable for "real" file buffer of source code. 🤷


I think the open bugs are legit to get solved in this PR. But all further improvements should be exported. This PR is already huge and you introduced a complete new big feature "section" in your plugin. Also you did already add tons of nice additions as reaction to my comments. 🙏

@pwntester
Copy link
Owner Author

pwntester commented Mar 1, 2021

Yeah, sorry the cite was not visible because it was actual a virtual text where I put a real > cite initiator before. I left a comment here regarding this virtual text. Atm it is very confusing. I don't know your intention behind it. I the user forgot which line he wanted to comment he can cancel and start again. Or maybe provide a hint in the file name the user sees in his status line?

Agreed, I will remove that virtual text

I have an open issue at the tressitter plugin. There they say it is not possible. How did you solve it. Could you leave a comment at nvim-treesitter/nvim-treesitter-refactor#12 ? But maybe your approach is not usable for "real" file buffer of source code. 🤷

will do

I think the open bugs are legit to get solved in this PR. But all further improvements should be exported. This PR is already huge and you introduced a complete new big feature "section" in your plugin. Also you did already add tons of nice additions as reaction to my comments. 🙏

agreed, will try to fix the bugs, and all suggestions can be moved into new issues

Thanks!
asdfasdf #94 asdasdf

@weilbith
Copy link
Contributor

weilbith commented Mar 1, 2021

Alright. I opened a bunch of new issues.
You can remove (or strike out) them from your feature todo list.
Also you can close all review conversations in this PR (as I can't).

This plugin is so damn amazing. Dreamed of it for a long time. 😍

@weilbith
Copy link
Contributor

weilbith commented Mar 1, 2021

Could you make the highlighting of the editable stuff have a lower priority? For me it does overwrite the highlighting of the Issue title, id and status. If I set only the background color for the OctoNvimEditable group it works fine. But for better reusability of my colorscheme, it would great to link it to a group that has back- and foreground color, but the other highlight groups like OctoNvimIssueTitle can still draw over it. Would be great!

@pwntester pwntester merged commit 2bf0f47 into master Mar 1, 2021
@pwntester pwntester deleted the add_reviews_to_prs branch March 1, 2021 23:06
Copy link
Owner Author

@pwntester pwntester left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final

Comment on lines +64 to +65
| thread | resolve| Mark a review thread as resolved |
| | unresolve | Mark a review thread as unresolved |
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

asfas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants