Beta-testing 'mini.animate'

[echasnovski]

Please leave your feedback about new 'mini.animate' module here. Feel free to either add new comment or positively upvote existing one.

Some things I am interested to find out (obviously, besides bugs):

• Are configuration and function names intuitive enough?
• Are default values of settings convenient for you?
• Is documentation and examples clear enough?

Thanks!

[debugloop]

I often get bounciness with default settings. I suspect it has to do with my scrolloff value, as thats the approximate bounce size (eye-balled...) and it also goes away with set scrolloff=0.

To repeat safely I can open any buffer with more lines than I have on screen and do ggG to see it, but in occurs in different situations too.

[jotacosta-fb]

I second that vim.opt.scrolloff = 0 makes bounce

[gsinclair]

Bug? This occurred when I opened a file from nvim-tree.

Error detected while processing WinScrolled Autocommands for "*":
E5108: Error executing lua ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1613: Error executing lua: ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:16
26: Cursor position outside buffer
stack traceback:
        [C]: in function 'nvim_win_set_cursor'
        ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1626: in function <...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1613>
        [C]: in function 'nvim_win_call'
        ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1613: in function 'apply_resize_state'
        ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1557: in function 'start_resize'
        ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1241: in function 'auto_resize'
        [string ":lua"]:1: in main chunk
stack traceback:
        [C]: in function 'nvim_win_call'
        ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1613: in function 'apply_resize_state'
        ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1557: in function 'start_resize'
        ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1241: in function 'auto_resize'
        [string ":lua"]:1: in main chunk

I can't offer any insight, sorry, but I presume mini.animate should never report an error when a file is opened.

[echasnovski]

I often get bounciness with default settings. I suspect it has to do with my scrolloff value, as thats the approximate bounce size (eye-balled...) and it also goes away with set scrolloff=0.

To repeat safely I can open any buffer with more lines than I have on screen and do ggG to see it, but in occurs in different situations too.

I don't use scrolloff, so didn't catch that. Reproduced it right now. Will look into it.

[echasnovski]

Bug? This occurred when I opened a file from nvim-tree.

Error detected while processing WinScrolled Autocommands for "*":
E5108: Error executing lua ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:1613: Error executing lua: ...im/site/pack/packer/start/mini.nvim/lua/mini/animate.lua:16
26: Cursor position outside buffer

I can't offer any insight, sorry, but I presume mini.animate should never report an error when a file is opened.

Yeah, this shouldn't happen. I know how to fix it quickly, but I would love to see at least some hints of how it can be reproduced. Did you open a file from 'nvim-tree' in new window while 'nvim-tree' itself remained visible?

[folke]

Thank you for this amazing new plugin!

mousescrolling is very weird and slow with animate though. Is there any way to disable animate specifically for mouse scrolling? Since that is already smooth anyway, without animate or neoscroll

[echasnovski]

Thank you for this amazing new plugin!

mousescrolling is very weird and slow with animate though. Is there any way to disable animate specifically for mouse scrolling? Since that is already smooth anyway, without animate or neoscroll

It is slow, because scrolling with many wheel turns result into many consecutive WinScrolled events. Each new one takes over the previous one at the current view state. As far as I researched, there is no way of knowing inside WinScrolled event which action triggered it. That is why it has a special mention in help file.

There are several ways to overcome this:

• Use high value for vertical mouse scrolling. Like set mousescroll=ver:25,hor:6. This will need one mouse wheel turn to go far enough. This is a method I adopted.
• Use set mousescroll=ver:1,hor:6. This will need aggressive mouse turns to go far enough.
• Use predicate for scrolling, such that it won't animate if total scroll is at or lower mouse scroll. Assuming default mousescroll:

local animate = require('mini.animate')
animate.setup({
  scroll = {
    subscroll = animate.gen_subscroll.equal({ predicate = function(total_scroll) return total_scroll > 3 end }),
  },
})

• Use different timing for small total scroll. It won't completely solve the problem (there will be an undershoot in case of aggressive mouse wheel turning), but it is a possible solution also:

local animate = require('mini.animate')
animate.setup({
  scroll = {
    timing = function(_, n) return math.min(5, 250 / n) end
  },
})

[folke]

The code below can detect when a WinScrolled event was due to mouse scroll.

If you'd incorporate it in mini, you would not need the schedule() inside the WinScrolled handler. Just always set it to false

  local scrolled = false
  for _, scroll in ipairs({ "Up", "Down" }) do
    local key = "<ScrollWheel" .. scroll .. ">"
    vim.keymap.set("", key, function()
      scrolled = true
      return key
    end, { noremap = true, expr = true })
  end
  vim.api.nvim_create_autocmd("WinScrolled", {
    callback = function()
      vim.schedule(function()
        scrolled = false
      end)
    end,
  })

  local animate = require("mini.animate")
  animate.setup({
    scroll = {
      enabled = false,
      timing = animate.gen_timing.linear({ duration = 150, unit = "total" }),
      subscroll = animate.gen_subscroll.equal({
        predicate = function(total_scroll)
          if scrolled then
            return false
          end
          return total_scroll > 1
        end,
      }),
    },
  })

[echasnovski]

The code below can detect when a WinScrolled event was due to mouse scroll.

If you'd incorporate it in mini, you would not need the schedule() inside the WinScrolled handler. Just always set it to false

  local scrolled = false
  for _, scroll in ipairs({ "Up", "Down" }) do
    local key = "<ScrollWheel" .. scroll .. ">"
    vim.keymap.set("", key, function()
      scrolled = true
      return key
    end, { noremap = true, expr = true })
  end

True. But one of the main objectives with this module was to not create any keymaps, as this is not what I would expect from animation plugin to do. I'll think about it, but at the moment having this kind of trade-off with mouse scroll seems appropriate.

And there is no vim.schedule() inside WinScrolled event per se, mainly because it would lead to flicker due to screen redraw.

[folke]

And there is no vim.schedule() inside WinScrolled event per se, mainly because it would lead to flicker due to screen redraw.

I know, I meant from the code I posted. I had to put in a schedule so it would still work in the predicate for my setup :)

[echasnovski]

I know, I meant from the code I posted. I had to put in a schedule so it would still work in the predicate for my setup :)

How about this then?

local mouse_scrolled = false
for _, scroll in ipairs({ "Up", "Down" }) do
  local key = "<ScrollWheel" .. scroll .. ">"
  vim.keymap.set("", key, function()
    mouse_scrolled = true
    return key
  end, { noremap = true, expr = true })
end

local animate = require("mini.animate")
animate.setup({
  scroll = {
    timing = animate.gen_timing.linear({ duration = 150, unit = "total" }),
    subscroll = animate.gen_subscroll.equal({
      predicate = function(total_scroll)
        if mouse_scrolled then
          mouse_scrolled = false
          return false
        end
        return total_scroll > 1
      end,
    }),
  },
})

[gsinclair]

Yeah, this shouldn't happen. I know how to fix it quickly, but I would love to see at least some hints of how it can be reproduced. Did you open a file from 'nvim-tree' in new window while 'nvim-tree' itself remained visible?

Correct.

nvim-tree was visible the whole time. The operation did not lead to a new window being created. Rather, the existing window was used to show the newly opened buffer. (You know, normal file explorer stuff!)

[echasnovski]

Yeah, this shouldn't happen. I know how to fix it quickly, but I would love to see at least some hints of how it can be reproduced. Did you open a file from 'nvim-tree' in new window while 'nvim-tree' itself remained visible?

Correct.

nvim-tree was visible the whole time. The operation did not lead to a new window being created. Rather, the existing window was used to show the newly opened buffer. (You know, normal file explorer stuff!)

This is strange. I do the same thing and it doesn't show error.

Did any window change size during this? Because that was an error from resize animation which should trigger only when window layout is same but some height and/or width has changed.