Add contributing guidelines to the plugin.

It can be copied from here, with some minor modifications.

README.md doesn't include documentation about all the different flags in the plugin.

It should be fixed by adding documentation about all the flags of the plugin. This documentation can be copied from the doc file of the plugin.

Release v0.2 of the plugin.

Should be close to the issue of #6.

Release the first actual version of the plugin.

It should add all the documentation just like #6, but it should also include publishing the plugin a bit more (in reddit for example).

There are certain parameters that the code can know how to generate by itself (for example, the current sha of the commit, the mr number, the project id, current file name).

This commit should add the functionality of running the needed commands to get these parameters and add them to the needed functions.

These parameters should still have the option to be configured by the command parameters, but the default should be by running these commands.

Add an option to create a comment on the current line of code.

In this issue, the new function that will be added should be able to add the new discussion thread on the current line of code.

This will support only adding comments on the current revision of the code. It will not support adding comments on old revisions of the code as for now (it might need to get the old revision of the code when it is adding the comment).

Gitlab's suggestion let you as a CRer suggest the fix on the given code in the merge request.,

This is done using a message from a specific format. It should be added to the plugin.

This should not be too hard since all that should be done is to construct the message as it is needed by GitLab.

The plugin should support a command that will get a range, and create a buffer with suggestion about this range of lines. The default value of the lines should be the current strings in them (so the user will only need to change the wanted information in it, without copying the rest of the data).

Hi,

thanks for your plugin. Unfortunately it does not completely work for me (might be a problem on my side). At the moment my company uses GitLab Community Edition 13.8.5.

MRInterfaceAddComment does work but adding comments on code lines does not. I edited the autoload/mr_interface.vim a little bit to get back the error. It's the same as if I try the generated curl-command directly in the command line. The result is always:
{"message":"400 Bad request - Note {:line_code=\u003e[\"can't be blank\", \"must be a valid line code\"]}"}
As can be seen here line_code should only be needed if you comment on multiple lines.

The feature to comment on multiple lines got added some time ago, maybe this is the problem.

Or maybe I just don't understand everything correctly. To get the base, start and head_sha I used the command from the gitlab doku here
curl --request GET --header "PRIVATE-TOKEN: xxxx" https://example.com/api/v4/projects/nnnn/merge_requests/mmmm

Despite beeing inside the repo and on the MR-Branches head the SHAs don't get calculated automatically. But I can use HEAD, HEAD~1 and so on. These SHAs are correct if I look at the curl command. Maybe I just understood the documentation wrong and this is the intended behaviour.

Tell me if you need more information.

Add an action that will get all the MR comments from gitlab and open them in Vim.

These comments should be opened in the quickfixlist (or some close list) and the user should be able to jump between the locations of the various comments in the code.

This should be asynchronous (it goes to gitlab and fetch content, we shouldn't make the user wait for this time).

The user should be able to get different types of comments using different commands (for example, a command for unresolved comments, a command for discussion threads and so on...)

Add option to see the MR comments on the code itself.

A sign should appear in the sign bar for every comment from gitlab. When the user will stand on this line, the actual comment should appear in the command line of vim. The user should have an option to open the full comment in a preview window.

The sign (and color) will be different for resolved and unresolved comments. Whenever there will be more than one unresolved comment on a line, the sign that will be used will be the sign for unresolved comments.

This should also add a command to toggle the signs.

Fill the readme with an explanation about what this plugin will do, and a roadmap of the issues that will be done in it.

Create a function that will add a new discussion thread about code to the gitlab mr with the given text in it, on the wanted line.

This function should add the new discussion thread on the code as it was added from the use. The function should get all the parameters from the user, without understanding anything by itself.

The function should use the same basic functions that adding general discussion threads and general comments issues has created.

By now, the plugin should use the authentication method of private tokens. This is quite a bad method because it sends important keys in plain text.

Understand what is the more secure method, and try to change the plugin and make it use it.

Create a function that will add a comment to the gitlab mr with the given text in it.

This function should really basic, and just make sure to talk with the interface of gitlab of adding new comments on an open merge request.

The function should get all the parameters when it is being called, without assuming anything or calculating anything by itself.

This function should currently use private tokens, since it is easier, even if less secured.

Let the user set flags to the curl command, in case he wants to customize it by himself.

Should add a user flag that will be added to the curl command.

Add default variables to the plugin.
They should be used in all the functions, and make it easier to use the different functions (the user will have to type less).

Release the first version of the plugin.

It includes tagging the code on the master branch, adding a release inside github and adding the plugin to vim.org

This version will be very simple, but it is a start and it should be usable (even if not very good).

Add some mappings to the plugin to make it easier to run commands.

Create good documentation for the plugin.

It should include:

• filling the README.md file with all the general information of the plugin.
• Creating a documentation directory for vim with helpfile, generating documentation on the code using vimdoc, and adding more general documentation for the plugin.

Fugitive has some commands that let the user see diff in the code (Gdiffsplit, Gvdiffsplit, Ghdiffsplit`, maybe more).

make the plugin support adding comments on code when looking at this diff.

This should make the function that adds discussion threads on the code really easy, and make the plugin actually good. After this issue, the plugin should become really usable for the first time.

The plugin is written without any tests in it. Add tests on all the functionality of the plugin.

It might not be possible to test all the functionality of the plugin (depending on whethere there are mocks in vimscript), but it is better to have some tests than none at all.

Currently, whenever there is a single quote in a comment that the user is adding, the comment breaks and no comment at all is being added to the MR.

This is a bug in the plugin, and it should be fixed. The fixed would probably be done by adding some kind of escaping to this character.

Change all the functions that add comments to the MR (regular comment, general discussion thread, and code discussion thread) to open a temporary buffer, let the user fill it, and then send the code from the temporary buffer to the MR.

It should be a lot easier to write the message in a buffer than to write it as a parameter to the function.

whenever there is an error of bad request, the plugin currently prints that the command was added successfully.

This error should be handled like all the other errors are currently being handled in the code.

The plugin is currently written as synchronic (I don't know how to write synchronically plugins as for now).

After the first version (v1.0) of the plugin is released, it should be refactored to be asynchronous.

Create a function that will add a discussion thread to the gitlab mr with the given text in it.

This function should be really basic, and just make sure to talk with the interface of gitlab of adding new comments on an open merge request. It should have the same interface as the function written in #2, and use the same internal functions.

The function should get all the parameters when it is being called, without assuming anything or calculating anything by itself.

Maktaba seems like a very good plugin for writing vimscripts.

Change the plugin to be such a plugin.

It would have been better to start with the plugin written in this format, but I want to release the first version and don't have the time to learn it right now.