No autocmd when opening QuickFix window

[andryandrew]

Disables firing of autocommands when opening the QuickFix window.

Fixes #1595. While the bug is ultimately neovim's, firing a CursorMoved more often than in vim is a neovim design choice.

[lervag]

I'm curious if this would prevent running "important" or "desired" autocmds. E.g., I personally have

augroup quickfix_autocmds
  autocmd!
  autocmd BufReadPost quickfix call personal#qf#adjust_height()
augroup END

where adjust_height is used to adjust the height of the window. Would not this PR disable this particular autocmd?

[lervag]

My simple test for this confirms my suspicion. Thus, I would prefer to not merge this and instead implement a different fix, if possible.

[andryandrew]

Oups, sorry 😅 I did not think this through enough.
We can just ignore the two culprits instead of all autocommands (with eventignore=CursorMoved,WinEnter)...

...but maybe it's better to go with a "redraw" just before the win_gotoid call? This too seems to fix the important part of the bug (the misbehaving motion keys), but leaves the "ghost" highlighting in the quickfix window.

Just a question though: why is the built-in matchparen still active alongside vimtex's own mechanism? Disabling it (or just loading it after vimtex's one, instead of before) also fixes the bug unfortunately, not in all situations.

[lervag]

Oups, sorry sweat_smile I did not think this through enough.
We can just ignore the two culprits instead of all autocommands (with eventignore=CursorMoved,WinEnter)...

No problem! And if possible it seems like a good idea to ignore specific autocommands! I think the main autocommands that are relevant that we don't want to ignore are ones such as the one in my example.

...but maybe it's better to go with a "redraw" just before the win_gotoid call? This too seems to fix the important part of the bug (the misbehaving motion keys), but leaves the "ghost" highlighting in the quickfix window.

That also sounds like a simple and OK solution. It should be added with a relevant comment (e.g. linking to this PR for motivation).

Just a question though: why is the built-in matchparen still active alongside vimtex's own mechanism? Disabling it (or just loading it after vimtex's one, instead of before) also fixes the bug unfortunately, not in all situations.

Good question. I guess the simple answer is "because Vimtex tries not to interfere with other plugins"? Is there a simple way to disable it that would not lead to unexpected situations for the user (e.g. a user may expected matchparen to be active in some buffers, but not the LaTeX buffers)?

[lervag]

Feel free to reopen if you have a proposal for an updated version.

[andryandrew]

I can submit a PR with the redraw workaround, but apparently I cannot reopen this one (or I don't see how). Is it a permission issue?

[lervag]

I can submit a PR with the redraw workaround,

Great, thanks, that would be appreciated!

but apparently I cannot reopen this one (or I don't see how). Is it a permission issue?

I have no idea. I can't reopen it either. So I guess you should just open a new PR. If/When you do, please link back to this PR and to the original issue, #1595 to help maintain the context.