concealer broken when promoting first element

[champignoom]

Prerequisites

• I am using the latest stable release of Neovim
• I am using the latest version of the plugin

Neovim Version

v0.9.0

Neorg setup

require('neorg').setup {
	load = {
		["core.defaults"] = {}, -- Loads default behaviour
		["core.norg.concealer"] = {}, -- Adds pretty icons to your documents
		["core.norg.dirman"] = { -- Manages Neorg workspaces
			config = {
				workspaces = {
					notes = "~/notes",
				},
			},
		},
	},
}

Actual behavior

With cursor on the first line with 'a', press '>>' to promote it, then the text becomes messed up:

** ◉
   1
***  ◎
    2
******    ✺

With the patch of the promo module from #817, the text will still be messed up but slightly differently:

*◉ a
   1
* ◎ b
    2
*   ✺ c

so this is more likely a concealer issue.

Expected behavior

not messed up:

 ◎ a
   1
  ○ b
    2
     ⤷ c

Note that, if an empty line is inserted before the first line so that everything starts from the second line:

** a
   1
*** b
    2
****** c

promoting on the second line with 'a' won't reproduce the bug and everything behaves as expected.

Steps to reproduce

Open test.norg, type

* a
  1
** b
   2
**** c

then ESC to enter normal mode, the text being concealed to

◉ a
  1
 ◎ b
   2
   ✺ c

Potentially conflicting plugins

No response

Other information

related: #292 (comment)

Help

Yes

Implementation help

No response

[champignoom]

The reason seems to be that the "bufwinenter" event is artificially considered to be at position (1,0), which costs the concealing quota on the first line.

[champignoom]

neorg/lua/neorg/modules/core/concealer/module.lua

Lines 1552 to 1554 in 3009adf

	if mode ~= "i" then
	module.private.debounce_counters[event.cursor_position[1] + 1] = module.private.debounce_counters[event.cursor_position[1] + 1]
	+ 1

This is likely a bug, because it's located under the if event.type == "core.autocommands.events.bufwinenter" branch, where event.cursor_position is irrelevant (and appears to be always {1,0}).

Maybe it was meant to be module.private.debounce_counters[start + 1]?

[vhyrro]

@champignoom you're totally right! That's a huge bug actually, as it means that this whole time the debounce counters
weren't working as intended 😭. Let me fix that.

[vhyrro]

Okay I pushed a commit that (at least on my end) fixes this problem, that was in fact the issue! Please do reopen if it's still broken for you :)