gitsigns spacing and colour about nvim-scrollview

[dstein64]

The spacing issue is addressed as of PR #130. When scrollview_always_show is used and a sign for gitsigns would correspond to multiple rows of the scrollview column, all those rows will be used.

@sho-87, can you provide steps for reproducing the other issue? Something like:

$ git clone <REPO>
$ git checkout <COMMIT>
$ nvim
# plus a list of edits to the file to reproduce the issue

[sho-87]

awesome! thanks for your speed

[sho-87]

@dstein64

to reproduce, here is a fresh config that bootstraps lazy and grabs scrollview and gitsigns at specific commits:

init.lua:

local lazypath = vim.fn.stdpath 'data' .. '/lazy/lazy.nvim'
if not vim.loop.fs_stat(lazypath) then
  local lazyrepo = 'https://github.com/folke/lazy.nvim.git'
  vim.fn.system { 'git', 'clone', '--filter=blob:none', '--branch=stable', lazyrepo, lazypath }
end ---@diagnostic disable-next-line: undefined-field
vim.opt.rtp:prepend(lazypath)

require('lazy').setup({
  {
    "lewis6991/gitsigns.nvim",
    commit = "078041e",
    config = function(_, opt)
      require('gitsigns').setup {
        signcolumn = true,
    }
    end
  },
  {
    "dstein64/nvim-scrollview",
    commit = "1d80f72",
    config = function(_, opts)
      require("scrollview").setup(opts)
      require("scrollview.contrib.gitsigns").setup(opts)
    end,
    opts = {
      always_show = true,
      column=40,
    }
  },
})

1. git init in a directory, create a new file, and commit it. I just used some random text like:

jkh
jklsdfh
sdf
sdf
sdf
sdf
sdf
sdf
sdf
sdfdsf
asdasdasd
isdfsdf

2. nvim using the config above
3. add a new line to the end of the file and you'll see this, which is the correct colour for an addition:
   
4. go to the line above and change it, and this is where it goes wrong:
   

the marker is still there for the line addition, but the colour that used to be the correct blue has now turned into purple

[dstein64]

The second issue is fixed in 5a7eb7e. A gitsigns change hunk could be comprised of a change and an addition. The existing code was assuming it was only a change, with no addition.

@sho-87, thanks for reporting the issue and providing the detailed reproduction steps. If you're still encountering a problem, please let me know with a new Issue or a comment here.