Don't allow comments on modified buffers

[jakubbortlik]

Feature Description

With the imply_local option for DiffView it is now possible to modify the "new" version of the files under review. A user can (by mistake or on purpose) modify a buffer and then attempt to create a comment around the modified lines that will throw this error: gitlab.nvim: Could not create discussion: POST https://.................merge_requests/8/discussions: 400 {message: 400 Bad request - Note {:line_code=>["can't be blank", "must be a valid line code"]}.

I think creating comments on files modified locally does not make sense, so there could be a mechanism that prevents this or at least warns the user that they are trying something odd. gitlab.nvim already checks that there are uncommited changes, but this only happens when starting the review. To successfully prevent the described error to happen, changes to the file on disk and buffer modification could be checked before creating a comment. Alternatively, nomodifiable could be set on the buffer in the "new" version.

Steps to reproduce the comment failure

1. Create a file.txt with the following old content:

abc
def
ghi

In a feature branch, modify the file like this (this modification is not the point yet, but it's necessary for the file to be part of the MR):

abc
def
ghi
jkl

2. In the feature branch, start the review (with gitlab.review)
3. In the new version delete the first line ("abc")
4. In the old or new version, try to create a comment on line "def" (in the old version it is line 2, in the new version it is now line 1). In both cases the creation fails.

[harrisoncramer]

This will be resolved by the upcoming refactor MR, thank you for reporting it.

[jakubbortlik]

Hi, this works very well.

One point to consider, though. The user can still do something like use DiffView's keybinding gf to open the file in a different tabpage, then they could make changes which would show up in the "new" version in the reviewer. This could be easily checked in the create_comment function in lua/gitlab/actions/comment.lua with something like:

  local is_modified = vim.api.nvim_buf_get_option(0, "modified")
  if is_modified then
    u.notify(
      "Cannot leave comments on a modified buffer. \n Please discard any changes.",
      vim.log.levels.WARN
    )
    return
  end

The question is to what lengths you want to go in preventing errors from irregular user behaviour. The user could manually set modifiable on a buffer and change it, or do more silly things, but it does not make sense for your plugin to check this. But opening the file in a different tab is I think part of a normal workflow and I can imagine modifying a buffer like this by mistake, so I think the above check of is_modified is reasonable.

[harrisoncramer]

EDIT -- Oh, I see what you're saying, I'll add this, pretty easy to do.