@bfredl
It fixes it for me, thanks!

It might not be easy to reproduce, but can be using the following minimal vimrc in Neomake's checkout:

set runtimepath+=$PWD
let g:neomake_open_list = 2
call neomake#quickfix#enable()

new
set filetype=sh
call setline(1, ['a="'])

Neomake sh

What triggers it appears to be placing signs in the custom quickfix that gets opened then.

For me it's also difficult to reproduce. I'm reasonably sure it's caused by vim-signify, and it only seems to happen when I open nvim with two split files on the command-line:

nvim -O <file1> <file2>

Both files must have changed lines (according to vim-signify), otherwise the bug doesn't trigger.

I don't know nearly enough about the drawing code, but your comment about just using the standard path sounds good. It's worth a shot. Then again, we've encountered Chesterton's fence a lot in old pieces of Vim :).

If were to entertain a guess, the special codepath might be because signs were introduced togheter with netbeans protocol, and thus the first UI feature expected to be redrawn mosty due to async events (i e something other that user input). But now we expect that async events can change mostly everything (window layout, buffer contents etc), so there is no strong argument to still special case signs.

@bfredl your guess is as good as anyone's (except for @brammool I suppose).

In any case, before a release we can experiment a bit (while adding tests when finding regressions). Your earlier comment about using value types is also... valuable ;).

Reduced to the following script

set cursorline
sign define piet text=>> texthl=Search
split
:exe ":sign place 3 line=2 name=piet file=" . expand("%:p")

Kept the hotfix for now with a test, a proper refactor can be separate PR.

Thanks for fixing it @bfredl! Looking forward to the refactor.