output of synID() sometimes wrong when text is concealed

[lacygoill]

Describe the bug

I have a mapping in help files to jump to the next help tag; it sometimes unexpectedly skip a tag.

This is because my mapping searches for a pattern describing a tag ('\\\@1<!|[#-)!+-~]\+|'), then it checks the syntax under the cursor; if the latter is not helpBar nor helpHyperTextJump, then the mapping searches again for the pattern, until it finds a match with the right syntax.

The issue is due to synID(), whose output is sometimes the ID of helpExample, while it should be the ID of helpBar.

To Reproduce

Write this code in /tmp/vim.vim:

syn enable
set cole=3 cocu=n lines=24 columns=80
nno cd :call Func()<cr>
fu Func()
    call search('|', 's')
    echom synIDattr(synID(line('.'), col('.'), 0), 'name')
endfu
h items()
exe "norm! /->items/e\r"

Now start Vim like this:

vim -Nu NONE -S /tmp/vim.vim

Press cd to invoke Func() which searches the next bar and echo the name of the syntax item under the cursor. The output is helpBar, which is correct.

Finally, press kk to move 2 lines upward, and press cd again; the cursor jumps to the same bar again, but this time, the output is helpExample, which is wrong.

Expected behavior

The output of synID() is always the ID of the syntax group helpBar; not sometimes the ID of helpBar, and sometimes the ID of helpExample.

Screenshots

Environment

• Vim version: 8.1 Included patches: 1-2315
• OS: Ubuntu 16.04.6 LTS
• Terminal: XTerm(322)

Additional Context

If the 'conceallevel' option is set to 0, the issue disappears; so the issue is probably related to the conceal mechanism.

---

If you press C-o to jump back to the original location, then press cd again, the output of synID() is correct (helpBar). After that, if you press kk to get back to the original location, then press cd, the output is wrong again (helpExample):

In this last gif, I included the cursor positions before jumping to the bar, and after (via the output of getcurpos()):

syn enable
set cole=3 cocu=n lines=24 columns=80
nno cd :call Func()<cr>
fu Func()
    let old_pos = getcurpos()
    call search('|', 's')
    let new_pos = getcurpos()
    echom 'old pos = '..join(old_pos, ',')..' new pos = '..join(new_pos, ',')..'    '..synIDattr(synID(line('.'), col('.'), 0), 'name')
endfu
h items()
exe "norm! /->items/e\r"

Notice how the cursor positions are always the same, including the curswant number, regardless of whether I press kk or C-o to get back to the original position. IOW, before pressing cd, I'm always in the exact same position, and afterward I always land in the exact same position; and yet, for some reason, the way I get back to the original position (kk or C-o) influences the output of the next synID(), which is completely unexpected.

[andymass]

Does the output of at synID stabilize if you call it more than once in the same position?

[lacygoill]

Yes, you're right. Invoking synID() twice fixes the issue. That's how I fixed my code for the moment.

I wanted to report this, but I was trying to gather more information. Unfortunately, I haven't had enough time. For example, I think the matchit or matchparen plugin (not sure which one) influences the issue (maybe vim-matchup too). The path the cursor follows to get back to the original position matters; if it passes over a parenthesis in a help example (highlighted by helpExample) – while matchit or matchparen is enabled – I think the issue doesn't occur.

[andymass]

Yes, I definitely saw a similar issue when developing vim-matchup and I worked around it exactly as you say. However, I never correlated the issue to conceal in particular so I'm not sure if it is the same or two different issues. I'm both cases I think syntax must have some global state which is not cleared properly.

[monkoose]

The bug is still present.