feat!: add stack upwards option

[0xAdk]

general idea: instead of having a lines and highlights arrays that we append to, we create an array of "rendered items" which then get converted into the lines and highlights arrays with correct ordering.

A render_item just contains the lines and render_item relative highlights.

Not sure about: https://github.com/0xAdk/fidget.nvim/blob/12f4be2e4f2e887b4aeec97b0d392fdd2c4794d6/lua/fidget/notification/view.lua#L144-L152
I went from string.gmatch to vim.gsplit since it's cleaner and in testing found gmatch implicitly converts from numbers to strings, so I added it explicitly.

Set stack_upwards to true by default since that was how legacy worked.

closes #152

[j-hui]

This is awesome, thanks for working on this!

general idea: instead of having a lines and highlights arrays that we append to, we create an array of "rendered items" which then get converted into the lines and highlights arrays with correct ordering.

A render_item just contains the lines and render_item relative highlights.

I really like the intermediate NotificationRenderItem, it makes the algorithm a lot easier to understand. I refactored things a little to simplify the main render() loop, mostly putting each NotificationRenderItem-generating subroutine in its own helper function. Since each render item is self-contained, this was really straightforward.

And then rather than separately reverse the list, I just iterate through the render items in the reverse order.

I went from string.gmatch to vim.gsplit since it's cleaner and in testing found gmatch implicitly converts from numbers to strings, so I added it explicitly.

I didn't realize vim.gsplit() existed, and you're right that it's a lot cleaner. We don't need to worry about converting numbers to strings, that's a type error. (I will add a separate check in a different commit to enforce that.)

Set stack_upwards to true by default since that was how legacy worked.

Sounds good to me. (Note to self: I need to re-record the demo GIF.)

[0xAdk]

one minor thing, instead of having

local foo = M.render_foo()
if foo then
	table.insert(render_items, foo)
end

can't you just have

table.insert(render_items, M.render_foo())

since table.insert(tbl, nil) doesn't do anything (I think; based on testing, couldn't find any docs about this).

[j-hui]

While that might be correct, I prefer it as I’ve written it because I think it makes it clearer that sometimes, nothing is inserted into the list.

(Micro-optimization hat on: we avoid the function call overhead to table.insert() when we don’t need it. But I don’t think this small overhead actually matters.)