LuaSnip
LuaSnip copied to clipboard
LuaSnip + texlab not working properly
I opened this issue https://github.com/latex-lsp/texlab/issues/503, but I'm not sure if it's texlab that's causing the problem. I noticed that it only happens if I don't jump to all fields and escape. Could this be related to luasnip or nvim-cmp?
Yes, that could very well be related to luasnip+formatting.
Could you do :lua Luasnip_current_nodes[vim.api.nvim_get_current_buf()].parent:dump() (prints the nodes' positions) after the text was duplicated? I'd assume the extmarks get messed up by the formatting (if a block of text is replaced, the marks that were inside it get pushed to either end).
:lua Luasnip_current_nodes[vim.api.nvim_get_current_buf()].parent:dump():
E5108: Error executing lua [string ":lua"]:1: attempt to index global 'Luasnip_curren
t_nodes' (a nil value)
stack traceback:
[string ":lua"]:1: in main chunk
:lua require("luasnip").session.current_nodes[vim.api.nvim_get_current_buf()].parent:dump()
1
false false
0 0
0 0
2
false true
0 0
17 0
3
true false
17 0
0 0
4
false false
0 0
8 0
5
false false
8 0
8 0
6
false false
8 0
8 0
7
false false
8 0
8 0
8
false false
8 0
8 0
9
false false
8 0
8 0
10
false false
8 0
8 0
\documentclass{article}
\begin{document}
\section{ok} % (fold)
\label{sec:ok}
% section section name (end)
\documentclass{article}
\begin{document}
\section{ok} % (fold)
\label{sec:ok}
% section section name (end)
\end{document}
Yes that's the correct one :D :facepalm: Normally these indices should be consecutive, here the marks are getting moved around. Sadly there's little we can do about that (except manually tracking changes and not relying on extmarks, but that's very much work) :/
This is using efm to format instead of texlab:
1
false false
3 0
3 9
2
false true
3 9
3 11
3
true false
3 11
4 11
4
false false
4 11
4 13
5
false false
4 13
5 0
6
false false
5 0
5 0
7
false false
5 0
5 0
8
false false
5 0
6 10
9
false false
6 10
6 22
10
false false
6 22
6 28
Is this the normal behavior? Efm does not duplicate it, only texlab does that.
That looks correct, you can see that all nodes are adjacent ((3,0)->(3,9), (3,9)->(3,11),...), which is the correct behaviour.
I guess efm does something nicer, eg. not formatting at all or only inserting/removing parts that need to be changed as opposed to texlabs' complete replacement of the buffer.
Should no longer happen after 6e951d8, I think