Vimtex: lc got error

[rjiang9]

When do the clean by <localleader>lc, I got error with Vim 8 on Windows 7:

Error detected while processing function vimtex#compiler#clean[1]...398[15]..vimtex#process#run[5]..55
line   2:
E484: Can't open file C:\Windows\TEMP\VIo774A.tmp

Any friend have any idea on how to fix it?

Thanks,

[j-jith]

Have you checked if that file exists? IIRC the tmp file in Windows should be in C:\Users\username\AppData\Local\Temp. Does your user have write permission to the system TEMP folder?

[rjiang9]

Thank you,J.
I wonder why it point to the system temp. Is there way to change it?

[j-jith]

The tmp file is created using the tempname() function in vim. You could perhaps set the $TMP variable in your vimrc by let $TMP=$HOME . "/tmp" (make sure this directory exists). This should ideally change the location of the tmp file. I'm not sure if this will work because I don't have a Windows machine to test this on.

[rjiang9]

This is very helpful, J. Thank you so much!!

[lervag]

@rjiang9 Could I first be somewhat rude and ask you to read about Markdown formatting? It is much easier to read your posts if you format them properly. I'm taking the liberty of updating your post now to make it more readable.

[lervag]

@j-jith Again thanks for pitching in. I think your answers are straight on and should solve the issue.

@rjiang9 Please let me know if anything else is unclear. I hope things work as expected with @j-jith's input.

[rjiang9]

Hi Karl,
Sorry for not following some of your rules when I first posted. @j-jith's suggestion let me reset my 'tmp' folder but unfortunately it does not solve the issue. It still complains that
Can't open file like VIo606.tmp in the new 'tmp' folder.

Thanks,

[lervag]

Strange. I have not encountered this before, and I have no real clue where to begin.

Could you please try to write a full minimal example as explained in the issue template.

[rjiang9]

I will, Karl. Thanks.

[j-jith]

@rjiang9, could you check which shell you're currently using in vim? You can do that by :set shell?.
If you are using the cygwin shell (since your previous issue was related to cygwin), could you change it to cmd.exe and see if the error persists? :h 'shell' should tell you how to change your shell. This should help in figuring out whether your issue is shell-related or something entirely different,

[rjiang9]

Hi @j-jith ,

I am off computer now. I will test it and report back tomorrow.

Thanks a lot

[rjiang9]

Hi @j-jith ,
Just check the shell in vim, it says it is using:
shell=c:\Windows\System32\cmd.exe

[j-jith]

I just got my hands on a Win 7 machine, and I too seem to be having the same issue. The error E484 occurs when the commands passed to the shell using system() are not properly escaped (see :h E484).

I have created a new branch at j-jith/vimtex/tree/win32-clean-E484 in which I have added some extra quotes while preparing the commands (in the s:process._prepare() function in process.vim). It seems to work on my machine without any errors.

@rjiang9, can you test this branch and see if it fixes your issue? I'm not sure how to configure Vundle to download from a specific github branch (I don't think it's even possible). So, you'll have to clone the branch and point Vundle to it. Or you can make the edits (it's just a single edit, in fact) that I have made to your local copy of vimtex.

[lervag]

@j-jith Thanks! I appreciate your effort. I won't accept the change immediately, but perhaps after some thought. First: I already know from personal testing that the current version works on Windows for some setups (e.g. mine). I also know that there are strange things on windows where seemingly equivalent systems don't act the same. There are closed issues on this where I with a lot of good help was still not able to figure it out. So, if we were to accept this change, we need to add some proper conditionals that only affect systems where the setup fails. I can test on my Windows machine where the current version should work. If it still works, then we could probably assume it won't break things. And if it fixes things for others, I guess the conclusion is easy.

But the changed quoting should only be done for windows systems, not Linux or OSX.

[j-jith]

@lervag I too don't think this should be accepted without further testing. That's why I haven't opened a pull request yet :)

Also, I have made sure that I've changed the quoting only for windows systems.

[lervag]

Great, good to hear. It would be good to make things more robust on Windows, so I'm all for good input here!

Note, just to be clear: I don't work on Windows machines, and so I don't really do any vimtex development for Windows. Thus I depend on contributions to improve things in this area.

[rjiang9]

@j-jith Hi J, sorry for the late reply. This is to confirm that the lc command error is gone after I use the files on your fork to replace the ones on my local.
Thanks for the hardword!

[lervag]

Good to hear.

@j-jith Are you able to send a pull request or to propose the required changes here?

[j-jith]

I've opened a pull request. It's only a minor edit.

But first I would like @rjiang9 to confirm that all the other commonly used commands are working as well. I unfortunately don't have access to a Windows machine at the moment.

[rjiang9]

@j-jith I just did some quick test on default mappings in the document, it looks fine to me.

[lervag]

Great, thanks! I'll accept the pull request. Please let me know if you should find something wrong with this afterwards.

[rjiang9]

@lervag I will. Thanks!

[horset]

Hello,

I would like to describe a strange situation based on this issue.

When I triggered <localleader>lv, it shows a command prompt and doesn't work.

If I change the following line in the function s:process._prepare() of process.vim back to remove the extra double quotes, <localleader>lv works, but <localleader>lc doesn't work again.

let self.prepared_cmd = '"' . l:cmd . '"'

changed back to

let self.prepared_cmd = l:cmd

The vimrc I use:

let g:vimtex_view_method = 'general'
let g:vimtex_view_general_viewer = 'SumatraPDF'
let g:vimtex_view_general_options = '-reuse-instance -forward-search @tex @line @pdf'

The environment I use:

• vimtex: commit 7b37cefb1cf1f91c413825bc45b09c52fb950c91
• OS: Winows 10
• Vim: 8.0 with gvim

Any suggestion?
Thanks.

[lervag]

Damn, I really dislike Windows!!! It seems impossible to find a robust implementation of this!

My suggestion is that someone who is proficient with Vim and Windows help me out by explaining how this should be written in order to be robust between different Windows configurations. I'm sorry to say that I have no idea how to make this better, and that my motivation is very low considering the fact that I never use Vim to edit LaTeX files on Windows systems.

Another thing that helps is opening a new issue where one makes things are explicit, clear and concise as possible. I think your post is close to this, @horset, so you could start by opening a new issue with the same content. If I have the time, I will boot up my Windows PC and see if I can reproduce the problem.

[li-ruijie]

One curious thing is that the command @horset highlighted above seems excessively redundant. It is nesting a cmd /c in a start that is suppose to trigger another instance of cmd. Is this appended on by vimrun or specified somewhere?

[lervag]

Ok, since the commit 6c172bd breaks things for old users I am reverting it. I am aware this will probably break things for e.g. @j-jith. However, we need to find a better way to solve this. As I've said, I hope there are someone out there with the knowledge and skills that might be able to help me find a way to solve this reliably. Windows compatibility is a pain, and every time we try to fix something it keeps biting back...

[lervag]

@horset As said, I've reverted, so things should work for you again now.

Anyone: Do you know why things work for some people while it does not work for others? It seems you are working from similar systems, but there must be something different..?

[j-jith]

@lervag I had tested commit 6c172bdf3bc89d0f5154e7c875b66d48baa60aee only on a Windows 7 machine. Perhaps other versions of Windows behave differently when it comes to quoting. I'm not a regular Windows user. So I'm not sure what exactly the underlying issue is.

Would it make sense to use a bash port on Windows instead of cmd? It would make things a lot more manageable.

[lervag]

Anything that would not be too much of a requirement for Windows users that would make things more manageable would be good, I think. Is it simple to install a bash port on Windows? I guess it would require users to set their shell settings different, right?

[j-jith]

Installing a bash-like shell on Windows should not be too difficult. There are easy installation packages for cygwin, msys, etc.

But changing the shell settings in vim might be a bad idea (especially if the user wants to keep the cmd experience intact). Instead, I would suggest a wrapper function which runs the command in the appropriate shell.

[lervag]

Hmm, I see. I don't really like wrapper functions too much, but if there is no other way...

In any case, I would be happy to consider any pull requests for this, and I will be happy to assist in implementing and improving the windows support. But I will probably not be doing this on my own. Just saying... :)

So, if we want to continue this effort, I propose the following roadmap:

1. Open a new issue to describe the main problems with the current implementation on Windows.

2. List the relevant locations in the vimtex code.

3. Suggest possible solutions or ideas for improving things.

[mbrengel]

I have the same issue, but I found that latexmk is working as expected despite the error message. Actually, Vim even managed to write to the temporary file in my case, which makes the error message even more puzzling. Anyway, to get rid of the error one can set silent to 0 here:
https://github.com/lervag/vimtex/blob/c49b470012b9d1d36ac8fa3e771f2e66e9c62b59/autoload/vimtex/process.vim#L31-L39
I realize that this is probably not a fix that should be integrated into the repository, but maybe this is helpful for other Windows users. The underlying reasons as to why this happens is probably related to the usage of the start command, which is used by vimtex if silent execution is requested. I can provoke this error in a bare Vim session (vim -u NONE) by executing :call system("start cmd"), which also gives me a similar error, i.e., E484: Can't open file C:\Users\michael\AppData\Local\Temp\VIoBEB9.tmp, but the command executes just fine. However, I don't know a enough about Vim, Vimscript or the idiosyncracies of the start command to fix this in a meaningful way.