lervag / vimtex

VimTeX: A modern Vim and neovim filetype plugin for LaTeX files.
MIT License
5.42k stars 389 forks source link

vimtex + nvim-cmp crash when typing *some* commands #2653

Closed dajuno closed 1 year ago

dajuno commented 1 year ago

Description

Hi all, the good: latex completion using nvim-cmp seems to be working generally. But when I type some commands, nvim and it's containing terminal crash.

For example, in the below MWE, typing \be (e.g., for \begin or \beta) will show completion for commands starting with be, then crash, making vimtex+nvim-cmp impossible to use together. Other latex commands are fine.

The crash always happens when typing \be after \begin{document}, but only about 50% of the time when typed in the preamble. Super weird.

Not sure if related, but with the setup below entering insert mode (by hitting i, a, o, etc) gives this error message:

E5108: Error executing lua [string "v:lua"]:1: attempt to index field 'utils' (a nil value)                  
stack traceback:
        [string "v:lua"]:1: in main chunk

This does not happen with my full config, where the crashes happen, too (and for more commands! e.g. \au, \da, ...)

Steps to reproduce

  1. Run nvim -u minimal.vim minimal.tex
  2. Type in the document body: \be
  3. Observe crash or repeat

minimal.tex

\documentclass{minimal}
\begin{document}
Test
\end{document}

minimal.vim

call plug#begin('~/.config/nvim/plugged')
    Plug 'hrsh7th/cmp-omni'
    Plug 'hrsh7th/nvim-cmp'
    Plug 'lervag/vimtex'
call plug#end()

lua << EOF
-- Adjust VimTeX config
vim.g.vimtex_view_method = "zathura"
vim.g.vimtex_syntax_enabled = 0
vim.g.vimtex_quickfix_enabled = 0

-- Setup nvim-cmp
cmp = require("cmp")
cmp.setup {
  sources = cmp.config.sources {
    { name = "omni", },
  },
}
EOF

Expected behavior

Should not crash.

Actual behavior

  1. error message whenever entering nvim's insert mode:

    E5108: Error executing lua [string "v:lua"]:1: attempt to index field 'utils' (a nil value)                  
    stack traceback:
           [string "v:lua"]:1: in main chunk
  2. nvim + terminal crash

Do you use a latexmkrc file?

No

VimtexInfo

System info:
  OS: Linux 6.2.1-arch1-1
  Vim version: NVIM v0.8.3
  Has clientserver: true
  Servername: /run/user/1000/nvim.72546.0

VimTeX project: minimal
  base: minimal.tex
  root: /home/david/mwe_tex
  tex: /home/david/mwe_tex/minimal.tex
  main parser: current file verified
  document class: minimal
  compiler: latexmk
    engine: -pdf
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
  viewer: Zathura
    xwin id: 0
lervag commented 1 year ago

Interesting. On my end, this does not lead to a crash, but I do get the error. I use this slightly different minimal.vim (which does not depend on vim-plug):

set runtimepath^=~/.local/plugged/vimtex
set runtimepath^=~/.local/plugged/cmp-omni/
set runtimepath^=~/.local/plugged/nvim-cmp/
filetype plugin on

lua << EOF
cmp = require("cmp")
cmp.setup {
  sources = cmp.config.sources {
    { name = "omni", },
  },
}
EOF

Steps required on my side:

I'm on neovim version v0.9.0-dev-1059+g2c9fbe34b2.

The error message is unknown to me, and I believe this may be an error with cmp-omni. Perhaps @hrsh7th would be friendly enough to join the discussion and help us figure it out?


By the way: please note that, IMHO, VimTeX syntax is better than Treesitter for LaTeX. Perhaps you disable VimTeX syntax because you've tried both and prefer Treesitter, but I do observe that a lot of people simply assume that Treesitter is better. Treesitter is awesome, but for some languages, like LaTeX, it is still a lot of work to make it as good as e.g. VimTeXs syntax scripts. -- Also, VimTeX has a few features that depend on the VimTeX syntax scripts.

hrsh7th commented 1 year ago

You should use local cmp = require('cmp') instead of cmp = require('cmp').

lervag commented 1 year ago

Yes, you are right - that seems to fix the issue. Thanks!

hrsh7th commented 1 year ago

The reproducible config is very helpful. Thanks!

lervag commented 1 year ago

No problem. I'm slightly annoyed that I didn't immediately recognize the missing "local" there... :p

dajuno commented 1 year ago

Thanks for your quick replies. The cmp config error was copied from the docs ;) https://github.com/lervag/vimtex/blob/640ffa4879d7c15fa6c5b8b458669f244ceff81c/doc/vimtex.txt#L4321

With your minimal.vim (only changed the paths), no crashes but completion does not work at all:

set runtimepath^=~/.config/nvim/plugged/vimtex
set runtimepath^=~/.config/nvim/plugged/cmp-omni/
set runtimepath^=~/.config/nvim/plugged/nvim-cmp/
filetype plugin on

lua << EOF
local cmp = require("cmp")
cmp.setup {
  sources = cmp.config.sources {
    { name = "omni", },
  },
}
EOF

Completion works when I use plugged -- here a more minimal config -- but it still crashes as before:

call plug#begin('~/.config/nvim/plugged')
    Plug 'lervag/vimtex'
    Plug 'hrsh7th/cmp-omni'
    Plug 'hrsh7th/nvim-cmp'
call plug#end()

lua << EOF
local cmp = require("cmp")
cmp.setup {
  sources = cmp.config.sources {
    { name = "omni", },
  },
}
EOF

My config folder is completely empty except for plugged containing the 3 plugins (up to date). I updated neovim to v0.9.0-dev-1094+ga0292b4e5f.


The vimtex config was copied from another issue, in real life I'm already using vimtex syntax highlights instead of treesitter :)

lervag commented 1 year ago

Ah, sorry: here's an updated minimal example:

set runtimepath^=~/.config/nvim/plugged/vimtex
set runtimepath^=~/.config/nvim/plugged/nvim-cmp
set runtimepath^=~/.config/nvim/plugged/cmp-omni
set runtimepath+=~/.config/nvim/plugged/cmp-omni/after
filetype plugin on

lua << EOF
local cmp = require("cmp")
cmp.setup {
  sources = cmp.config.sources {
    { name = "omni", },
  },
}
EOF

silent edit test.tex

If you start nvim --clean -u minimal.vim then immediately start typing, then things should work. At least, they work on my side.

lervag commented 1 year ago

And thanks for pointing out the error in the docs!

dajuno commented 1 year ago

Great, your last example works. I'll try to "rebuild" from there, without vim-plug.

Thanks for the instant support and all your work here!

lervag commented 1 year ago

Notice that the --clean is important when testing; if you do nvim -u minimal.vim then you will also load your personal customizations from ~/.config/nvim/plugin* and similar. You can check by inspecting :scriptnames with the different variants.

Also, glad to help! Let me know if you need more help.

dajuno commented 1 year ago

I'd like to share some intermediate results: I tried adding packer.nvim to the MWE:

vim.cmd [[packadd packer.nvim]]

require('packer').startup(function(use)
    use 'wbthomason/packer'
    use 'hrsh7th/cmp-omni'
    use 'hrsh7th/nvim-cmp'
    use 'lervag/vimtex'
end)

local cmp = require("cmp")
cmp.setup {
  sources = cmp.config.sources {
    { name = "omni", },
  },
}

Steps:

However: So far I've been using urxvt (rxvt-unicode v9.31) terminal. I just tried XTerm without any issue, no crashes. urxvt still works if I use --clean and the runtime path method. Very strange.

BTW, I haven't seen any crashes with anything other than latex.

Any ideas how to proceed? Thank you!

lervag commented 1 year ago

I'd like to share some intermediate results: I tried adding packer.nvim to the MWE:

Do I understand correctly that the minimal example where we just manually set the runtimepath now works as expected for you in all cases? And that the errors reappear when you add packer or vim-plug to the mix?

Steps: …

I assume that the second step is to add a new ~/.config/nvim folder and init.lua with the posted contents?

However: So far I've been using urxvt (rxvt-unicode v9.31) terminal. I just tried XTerm without any issue, no crashes. urxvt still works if I use --clean and the runtime path method. Very strange.

When things crash, do you see any error messages? The error message from earlier, is that always gone now?

Are you observing a difference between running with nvim --clean -u test.vim and nvim -u test.vim?

dajuno commented 1 year ago

Sorry, it was too late probably, I can't replicate this anymore. Probably config confusion, just as you said.

But I could narrow down the issue to a conflict with my colorscheme (https://github.com/RRethy/nvim-base16):

Using uxrvt, the exact steps are:

  1. mv ~/.config/nvim ~/.config/nvim.bak && rm -rf ~/.local/share/nvim/site/pack/packer/ && git clone --depth 1 https://github.com/wbthomason/packer.nvim ~/.local/share/nvim/site/pack/packer/start/packer.nvim
  2. nvim -u init.lua
  3. :PackerInstall, quit
  4. nvim -u init.lua minimal.tex
  5. insert \be [no crash]
  6. :colorscheme base16-espresso
  7. insert \be

This leads to a crash of urxvt (Seg fault) with the following init.lua:

vim.cmd [[packadd packer.nvim]]

require('packer').startup(function(use)
    use 'wbthomason/packer.nvim'

    use 'hrsh7th/cmp-omni'
    use 'hrsh7th/nvim-cmp'

    use 'lervag/vimtex'

    use 'RRethy/nvim-base16'
end)

-- adapted from vimtex docs:
local cmp = require("cmp")
cmp.setup.filetype('tex', {
    formatting = {
        format = function(entry, vim_item)
            vim_item.menu = ({
                omni = (vim.inspect(vim_item.menu):gsub('%"', "")),
                buffer = "[Buffer]",
                -- formatting for other sources
            })[entry.source.name]
            return vim_item
        end,
    },
    sources = {
        { name = 'omni' },
        { name = 'buffer' },
        -- other sources
    },
})

The crash after selecting a base16 colorscheme does not occur in any the following cases:

So there seems to be some conflict between this specific formatting and https://github.com/RRethy/nvim-base16

And no, the error message does not show, it was just an unrelated error in the first MWE.

lervag commented 1 year ago

Cool. Thanks for the update. I believe the issue has to do with either 1) colors, or 2) unicode glyphs. But it is hard to say. I believe you are on Arch Linux; if so, which urxvt are you using? I use rxvt-unicode-truecolor-wide-glyphs available from AUR.

dajuno commented 1 year ago

Yes exactly, rxvt-unicode-truecolor-wide-glyphs from AUR. I'm setting base16 colors from here in my .Xressources. Commenting all color definitions, the behavior changes a bit: now it crashes on typing \beg instead of \be ;) I commented all settings in .Xresources, except a font (just setting Liberation Mono). Still crashes. I guess I'll have to choose between the nice vimtex completions formatting and my nvim colorscheme for now.

lervag commented 1 year ago

I tried to follow your steps, but on my end, there is no crash. Things work as expected. Not sure what the problem is. Perhaps it is the .Xresources. Strange stuff; sorry I can't be of more help.

dajuno commented 1 year ago

Yes, thank you for your help. I've tried with an empty .Xresources (except mandatory font setting), to no avail. However, other rxvt-unicode packages do work and I narrowed the issue down to the enable-wide-glyphs.patch of the rxvt-unicode-truecolor-wide-glyphs. I'll let you know, for the sake of completeness, if I find a solution :)

lervag commented 1 year ago

Yes, thank you for your help.

My pleasure.

I've tried with an empty .Xresources (except mandatory font setting), to no avail. However, other rxvt-unicode packages do work and I narrowed the issue down to the enable-wide-glyphs.patch of the rxvt-unicode-truecolor-wide-glyphs. I'll let you know, for the sake of completeness, if I find a solution :)

Yes, please do. I use the same package, so it is strange that I'm not able to properly reproduce this. We should have close to identical systems, it seems - except I'm om neovim nightly from AUR. You could try updating neovim?

mrdotx commented 1 year ago

@dajuno: Hi, I'm the creator of rxvt-unicode-truecolor-wide-glyphs and I've tried to reproduce your crash (incl. cmp-omni, nvim-cmp, vimtex, nvim-base16(espresso), etc), unfortunately without success.

As @lervag had written, it is most likely that you have a problem in your config files. I don't know, but could it be that there are hidden control characters in them?

Another possibility that i could imagine would be your locale. What have you defined in your locale.gen?

dajuno commented 1 year ago

Hi @mrdotx, thanks for chiming in! strange... My locale.gen only has en_US.UTF-8 UTF-8 uncommented. @lervag: I tried with the AUR package neovim-nightly-bin, same issue. My minimal .Xresources is

$ xrdb -q
URxvt.font: xft:Liberation Mono:size=8:style=Regular

nothing weird. Do you have any suggestions which config files/settings I should check?

mrdotx commented 1 year ago

There was a time when there were significant problems with libxft and unicode characters. So just to be sure, you are using libxft and not libxft-bgra?

I have a file with a large amount of unicode characters in my repos (unicode-symbols). Please check if you can open the file with vim and/or another editor.

dajuno commented 1 year ago

Ok I found the issue. Most of the unicode symbols were not displayed properly and I realized that I didn't have the Symbola font installed. With ttf-symbola from AUR everything works now! Thank you for the hint! I don't know if it should be clear that symbola needs to be installed? I only had nerd-patched fonts. Anyway, thank you all!

PS: I'm using libxft 2.3.7-1 but tried libxft-git, too

mrdotx commented 1 year ago

Great that you found a solution for your Problem (I still can't reproduce it), but this can only be a correlation. It is not a requirement to install an emoji font like joypixels, noto emoji or symbola. The only thing that should happen when a character/glyph is not found in the installed fonts is that those annoying squares are displayed.

I think a more plausible explanation is that your font-cache was some kind of corrupted and after you installed a font related package the font-cache was recreated. However, I can't say that for sure...

Just in case there is someone who has similar problems. Try first to recreate the font-cache:

sudo fc-cache -vf

Thanks to all!

dajuno commented 1 year ago

Strange. Just to check I removed ttf-symbola, rebuilt the font-cache and nvim crashes in the same way. I really don't know enough here, but in the system log this utf 8 arrow in the core dump message seems a little weird... Mar 06 20:54:33 anarres systemd-coredump[37255]: [🡕] Process 37084 (urxvt) of user 1000 dumped core. Without symbola, i.e., in the situation where I have the crashes, I only see the rectangle.

lervag commented 1 year ago

Thanks to all!

@mrdotx Thanks to you too! I'm a very happy user of rxvt-unicode-truecolor-wide-glyphs :D

@dajuno You could inspect the core dump. E.g. with coredumpctl info 37084 (last number is the PID of the process that crashed). Perhaps that would be useful to find where it crashed? Another possibility could be to start urxvt from xterm, in which case you may see an error message when urxvt and neovim crashes?

dajuno commented 1 year ago

I posted the stack trace here which attracted @mrdotx apparently :)

 Stack trace of thread 37621:
                #0  0x00007efe50d6c7b7 n/a (libc.so.6 + 0x1537b7)
                #1  0x00007efe5127c4a7 n/a (libX11.so.6 + 0x674a7)
                #2  0x000055d0f8380754 _ZN9rxvt_term11scr_refreshEv (urxvt + 0x2d754)
                #3  0x000055d0f83811c9 _ZN9rxvt_term5flushEv (urxvt + 0x2e1c9)
                #4  0x000055d0f839bcb4 ev_invoke_pending (urxvt + 0x48cb4)
                #5  0x000055d0f839d351 ev_run (urxvt + 0x4a351)
                #6  0x000055d0f837c44d main (urxvt + 0x2944d)
                #7  0x00007efe50c3c790 n/a (libc.so.6 + 0x23790)
                #8  0x00007efe50c3c84a __libc_start_main (libc.so.6 + 0x2384a)
                #9  0x000055d0f8380f05 _start (urxvt + 0x2df05)
                ELF object binary architecture: AMD x86-64

When I run urxvt from xterm I only get a Segmentation fault. I'm still curious to find the real reason for this, but for now everything seems to be working...

lervag commented 1 year ago

I'm still curious to find the real reason for this, but for now everything seems to be working...

I can relate to that curiosity; but "everything seems to be working" is also generally good :)