Weird cmd prompt pop up when compiling

[resort09]

Description

Hi everyone, I am a beginner of Nvim and GitHub. I know almost nothing about the cool techy knowledge (programming, operation system, etc.). However, as my study gets more math-intense, I was trying to use latex to document lecture notes and all kinds of writings. And I finally found the combination of Nvim+Vimtex has been proved to be a feasible solution.

After days' struggling, I finally made my Nvim and Vimtex work. It could compile and produce pdfs. However, two problems showed.

1. When compiling, a weird cmd prompt popped up. And I can't input anything into this cmd prompt.

Cmd.mp4

2. After I closed Sumatrapdf and wanted re-compile the .tex again, compiler stopped. And it won't compile until I \ll or VimtexCompile at the second time.

stopped.mp4

And the closest case I found is #2601, however, my problem didn't get fixed when I run Nvim as Administrator.

I really appreciate any comments and/or advice! Also, I am quite new to GitHub, please let me know if I missed any information or failed to follow GitHub rules! Thank you!

Steps to reproduce

1. Set init.vim file as below.

call plug#begin()

Plug 'lervag/vimtex'
Plug 'SirVer/ultisnips'

call plug#end()

let g:tex_flavor='latex'
let g:vimtex_compiler_method = 'latexmk'
let g:vimtex_view_general_viewer='sumatrapdf'
let g:vimtex_quickfix_mode=0
let g:tex_conceal='abdmg'

2. Edit .tex file as below.

\documentclass{article}
\begin{document}
\[x^2+y^3+6^e\]
\[xy^3\]
di
thi
\end{document}

3. \ll, the Problem 1 showed.
4. Close cmd prompt and PDFviewer, \\, then it suggest compiler stopped.
5. \ll again, worked.

Expected behavior

1. No cmd prompt window popped up.
2. I can compile again after I close the PDFviewer. (No need to compile twice and failed the first one)

Actual behavior

1. A cmd prompt poped up.
2. After I close the PDFviewer and wanted to compile again, compiler stopped. I needed to \ll the second time to make it work.

Do you use a latexmkrc file?

No

VimtexInfo

info:
  OS: LASTRESORT (Microsoft Windows 11 Home)
  Vim version: NVIM v0.9.0
  Has clientserver: true
  Servername: \\.\pipe\nvim.6356.0

VimTeX project: text
  base: text.tex
  root: C:\Users\stard
  tex: C:\Users\stard\text.tex
  main parser: current file verified
  document class: article
  compiler: latexmk
    engine: -pdf
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
    job: 
      jobid: 11
      output: C:\Users\stard\AppData\Local\Temp\nvim.0\85e4l9\0
      cmd: set max_print_line=2000 & latexmk -verbose -file-line-error -synctex=1 -interaction=nonstopmode -pdf -pvc -view=none -e "$compiling_cmd = ($compiling_cmd ? $compiling_cmd . ' ^& ' : '') . 'echo vimtex_compiler_callback_compiling'" -e "$success_cmd = ($success_cmd ? $success_cmd . ' ^& ' : '') . 'echo vimtex_compiler_callback_success'" -e "$failure_cmd = ($failure_cmd ? $failure_cmd . ' ^& ' : '') . 'echo vimtex_compiler_callback_failure'" "text.tex"
      pid: 9048
  viewer: General
    job: 
      pid: -
      cmd: sumatrapdf -reuse-instance -forward-search "C:\Users\stard\text.tex" 7 "C:\Users\stard/text.pdf"
  qf method: LaTeX logfile

[lervag]

After days' struggling, I finally made my Nvim and Vimtex work. It could compile and produce pdfs. However, two problems showed.

I believe it is really only one problem. And I'm sorry to say I don't
immediately know how to help with that. But I'll try.

I'll first comment the "non-problem":

2. After I closed Sumatrapdf and wanted re-compile the .tex again, compiler stopped. And it won't compile until I \ll or VimtexCompile at the second time.

When you do \ll, you ask VimTeX to start the compiler. It does, and it will start in the background and recompile whenever you save your latex project. When you type \ll, you will stop the compiler. This is as expected. The third \ll starts the compiler again.

Steps to reproduce

1. Set init.vim file as below.

You can simplify this. On Windows, SumatraPDF should be automatically used as the viewer. And latexmk is the default compiler. The g:tex_... options are not relevant. Thus, you can simplify to this:

call plug#begin()

Plug 'lervag/vimtex'
Plug 'SirVer/ultisnips'

call plug#end()

let g:vimtex_quickfix_mode=0

Actual behavior

1. A cmd prompt poped up.

I know that VimTeX with SumatraPDF should work well for most people on Windows. However, I do not use it myself and I don't even have a windows machine. Thus, it is hard for me to debug this type of issue. Sorry!

Let's start with the simple question: is there any change after simplifying your config as explained above?

Also, did you read the docs, i.e.:

• :help vimtex-faq-windows
• :help vimtex-view-sumatrapdf

Finally, as a potential solution, you could look into using WSL to use neovim and VimTeX in a simple Linux system on Windows. In that case, :help vimtex-faq-sumatrapdf-wsl is also a relevant read.

[resort09]

When you do \ll, you ask VimTeX to start the compiler. It does, and it will start in the background and recompile whenever you save your latex project. When you type \ll, you will stop the compiler. This is as expected. The third \ll starts the compiler again.

Thank you for explaining that!

You can simplify this. On Windows, SumatraPDF should be automatically used as the viewer. And latexmk is the default compiler. The g:tex_... options are not relevant. Thus, you can simplify to this:

Also thank you for suggesting doing this, however, the problem is still there. But I find if my PDFreader has been opened before compilation, the cmd will not pop out (the cmd window flashes but not stay). I guess this "probelm" has something to do with the PDF reader. Since this does not really affect me writing and editing, I will let it be there before I find the solution. I will try to reproduce this problem and make some tests using other's PC. Something setting relates to PDFreader probably was accidentally changed, I assume.

[lervag]

When you do \ll, you ask VimTeX to start the compiler. It does, and it will start in the background and recompile whenever you save your latex project. When you type \ll, you will stop the compiler. This is as expected. The third \ll starts the compiler again.

Thank you for explaining that!

No problem :)

You can simplify this. On Windows, SumatraPDF should be automatically used as the viewer. And latexmk is the default compiler. The g:tex_... options are not relevant. Thus, you can simplify to this:

Also thank you for suggesting doing this, however, the problem is still there. But I find if my PDFreader has been opened before compilation, the cmd will not pop out (the cmd window flashes but not stay).

That was not really unexpected.

I guess this "probelm" has something to do with the PDF reader.

No, the problem has to do with how VimTeX opens SumatraPDF. And to improve it I would really like to have someone who is able to also work with the VimTeX code to help me figure out a better solution. Unfortunately, I do not know of/remember any active VimTeX users that uses Windows that is also comfortable with experimenting with the code and code changes.

Since this does not really affect me writing and editing, I will let it be there before I find the solution.

I'm sorry to say that I can't think of anything better as a workaround than opening the PDF viewer manually.

[resort09]

I'm sorry to say that I can't think of anything better as a workaround than opening the PDF viewer manually.

Please don't say that! I really appreciate for your help and constructive advice!

No, the problem has to do with how VimTeX opens SumatraPDF.

I just tried Vimtex+Latex+SumatraPDF on another PC that has never been used for that, and the same problem showed up. I think you are right and the problem is a general one. Also, I just find the same problem in the pull request #2627.

Thanks again for your prompt response and help!

[nitxy]

I am fairly new to texing in nvim and the cmd prompt pop up bothers me too. Here is my attempt at a workaround.

It seems that Vimtex utilizing cmd /c SumatraPDF to open the viewer is what causing this. I found out that the pop up would not appear using cmd /c start /b "" SumatraPDF.

So I wrote an autocmd calling this command every time I start editing a .tex or .latex file. Here's my implementation in lua

function open_sumatra_pdf()
    local pdf_file = vim.fn.expand('%:r') .. '.pdf'
    if vim.fn.filereadable(pdf_file) == 0 then
      pdf_file = ""
    end
    local cmd = 'cmd /c start /b "" SumatraPDF -reuse-instance ' .. pdf_file
    os.execute(cmd)
end

vim.api.nvim_create_autocmd({"BufReadPost"}, {
  pattern = {"*.tex", "*.latex"},
  callback = open_sumatra_pdf,
})

Every time a tex file is open, SumatraPDF will start and open the corresponding pdf file if exist, similar to TeXworks. Compiling will not cause a pop up again as Vimtex is using the same instance of SumatraPDF.

Hope this help.

[lervag]

@resort09

I'm sorry to say that I can't think of anything better as a workaround than opening the PDF viewer manually.

Please don't say that! I really appreciate for your help and constructive advice!

<3

No, the problem has to do with how VimTeX opens SumatraPDF.

I just tried Vimtex+Latex+SumatraPDF on another PC that has never been used for that, and the same problem showed up. I think you are right and the problem is a general one. Also, I just find the same problem in the pull request #2627.

Thanks again for your prompt response and help!

Ok, so, it seems there is some form of regression then.

I am fairly new to texing in nvim and the cmd prompt pop up bothers me too. Here is my attempt at a workaround.

@nitxy Great, I'm glad you are pitching in! Perhaps we can solve this
together!

It seems that Vimtex utilizing cmd /c SumatraPDF to open the viewer is what causing this. I found out that the pop up would not appear using cmd /c start /b "" SumatraPDF.

By default, VimTeX will use the following command:

cmd /s /c "SumatraPDF -reuse-instance -forward-search "C:\path\to\text.tex" 123 "C:\path\to\text.pdf""

If you want to test with some minimal implementation, then the following should be more or less the same as what VimTeX is doing now:

local cmd = [[cmd /s /c "SumatraPDF -reuse-instance -forward-search "C:\path\to\text.tex" 123 "C:\path\to\text.pdf""]]
jobstart(cmd, { detach = true })

You could also directly use the API from VimTeX:

local cmd = [[SumatraPDF -reuse-instance -forward-search "C:\path\to\text.tex" 123 "C:\path\to\text.pdf"]]
local job = vim.fn["vimtex#jobs#start"](cmd, { detached = true })
-- now you can inspect the "job" object, which has some relevant properties
print(vim.inspect(job))

Perhaps you could look into which of cmd /s /c ... or cmd /c start /b ... that is correct to use here?

[lervag]

And yes, you are right about #2627; it seems @archerc never responded to my feedback. I don't mind working on this, but it needs to be a collaboration with someone who can test on Windows.

[lervag]

It seems I made an important change all the way back in 2021 when I changed to newer apis:

7d8d92a#diff-5dfc6e98658ea0afff17d250db4ad5f3a92a7abcb65a4242ee88432803852f7fL158-L166

I believe there was a discussion about this, but I don't remember it.

[lervag]

It seems the most relevant discussion was #2195, which is the PR that introduced these changes. But there is no talk about this particular thing. Perhaps it is really a regression?

[lervag]

Sorry for all the comments - should have finished my investigations before replying. But, it seems we need to determine the best command string on Windows. I believe the alternatives are:

• cmd /s /c ... (this is what we use today and have used since October 2021)
• cmd /c start /b ...
• start /b cmd /s /c ... (this seems to be the cmd string used before October 2021)

The code that needs to be changed is here:

vimtex/autoload/vimtex/jobs/neovim.vim

Lines 9 to 11 in e9ad2be

	let l:job.cmd = has('win32')
	\ ? 'cmd /s /c "' . a:cmd . '"'
	\ : ['sh', '-c', a:cmd]

[nitxy]

I tried running

local cmd = [[cmd /s /c "SumatraPDF -reuse-instance -forward-search "C:\path\to\text.tex" 123 "C:\path\to\text.pdf""]]
vim.fn.jobstart(cmd, { detach = true })

with cmd /s /c start /b ... and start /b cmd /s /c .... Pop up appears in both cases.

But actually, if I just remove the { detach = true } option, the cmd window will not appear. The issue goes away when I modify the following to v:false. The editor is usable too.

vimtex/autoload/vimtex/jobs/neovim.vim

Lines 57 to 58 in e9ad2be

	if self.detached
	let l:options.detach = v:true

To begin with, I arrive at cmd /s /c start /b when I tried to start SumatraPDF from powershell, Just plain SumatraPDF or cmd /s /c SumatraPDF, the command prompt would be unusable until exiting the program. Maybe the behavior when running from vim is different? The autocmd I wrote without start /b works fine too.

[lervag]

I tried running

local cmd = [[cmd /s /c "SumatraPDF -reuse-instance -forward-search "C:\path\to\text.tex" 123 "C:\path\to\text.pdf""]]
vim.fn.jobstart(cmd, { detach = true })

with cmd /s /c start /b ... and start /b cmd /s /c .... Pop up appears in both cases.

Ok, thanks for checking!

But actually, if I just remove the { detach = true } option, the cmd window will not appear.

Very interesting! Then this may be the a solution, actually. The reason for adding the detach = true is to have the viewer not close when you close neovim/Vim. We could either 1) make an option, or 2) just revert this particular change. I can open a PR and have you and other people test and comment.

[lervag]

Related issue: #2401. This explains why the detach = true was added. I made a PR now where I simply set it to false on Windows: #2717. I would be very glad if someone could pull it and test if it resolves this issue.

[georgejean]

Here are the results of my tests. First, my config (with lazy.nvim):

local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "https://github.com/folke/lazy.nvim.git",
    "--branch=stable", -- latest stable release
    lazypath,
  })
end
vim.opt.rtp:prepend(lazypath)

vim.g.mapleader = " " 
vim.g.maplocalleader = " "
require("lazy").setup({
{
    "lervag/vimtex",
    -- pull from the specific branch and commit :
    branch = [[feat/view-general-windows]],
    commit = "da7870b69cc0468d4852aeabee0beef0b76ecdf4",
    init = function()
      -- Live compilation
      vim.g.vimtex_compiler_latexmk = {
        build_dir = ".out",
        options = {
          "-shell-escape",
          "-verbose",
          "-file-line-error",
          "-interaction=nonstopmode",
          "-synctex=1",
        },
      }
      vim.g.vimtex_view_general_viewer = "SumatraPDF"
      vim.g.vimtex_view_general_options = [[-reuse-instance -forward-search @tex @line @pdf]]
      vim.g.vimtex_fold_enabled = true
    end,
    opts = { patterns = { "*.tex" } },
    config = function(_, opts)
      vim.api.nvim_create_autocmd({ "BufRead", "BufNewFile" }, {
        pattern = opts.patterns,
        callback = function()
          vim.cmd [[VimtexCompile]]
        end,
      })
    end,
  },
})

then here is what I get without your fix (I've commented the two lines

branch = [[feat/view-general-windows]],
commit = "da7870b69cc0468d4852aeabee0beef0b76ecdf4",

and then sync)

Note : In Windows Terminal, in advanced settings, End of profile behavior must be set to Automatic otherwise the popup window triggered by <leader>lv doesn't close :

and here is the result with the fix :

All seems to work as expected.
One final note : for backward search, I use
cmd /c start /min "" nvim --headless -c "VimtexInverseSearch %l '%f'"
in SumatraPDF's Preferences->Options as suggested by the doc.

[lervag]

Thanks @georgejean for testing! I believe the change is more or less harmless and leads to a more desired behaviour. I've therefore merged #2717.

[georgejean]

In fact, using nvim --headless -c "VimtexInverseSearch %l '%f'" in SumatraPDF/Preferences/Options seems to work even better for backwards search with your fix (tested on two configs).