HTML conversion on Windows fails to correctly convert some wiki links

[adi93]

Vimwiki2HTML converts some links wrongly on Windows. I have tested this on Windows 10
TL;DR: Windows backslashes are causing a problem.

Setup

Output of :VimwikiShowVersion command:

Os: Windows
Vim: 802
Branch: dev

Revision: da9ef92

Date: 2020-06-16 23:21:41 -0400

Syntax I am using: default

Current vimwiki settings:

let wiki_1 = {}
let wiki_1.path = '~/wiki/'
let wiki_1.path_html = '~/wiki/html/'
let wiki_1.index = 'index'
let wiki_1.template_path = '~/notes/templates/'
let wiki_1.template_default = 'default'
let wiki_1.template_ext= '.html'

let g:vimwiki_list = [wiki_1]
let g:vimwiki_table_mappings = 0

File structure: I have the following files on Windows (On Windows, ~ translates to C:\Users\user) :

C:\Users\user\wiki\index.wiki
C:\Users\user\wiki\foo\bar\abc.wiki

Contents of index.wiki file:

= Home =
[[./foo/bar/abc|Link to abc file]]

Contents of abc.wiki file:

= ABC =
[[../../index|Link to home]]

Steps to reproduce

Open the abc.wiki file and run :Vimwiki2HTML.

Bug

After conversion, the "Link to home" link in abc.html should point to C:\Users\user\wiki\html\index.html. Instead, it points to C:\Users\user\wiki\html\foo\bar\index.html, which does not exist.

Reason for bug

1. The wikifile variable passed to the convert_file function in html.vim is being passed as C:\Users\user\wiki\foo\bar\abc.wiki (line 1646 in html.vim.), which sets the global variable current_wiki_file.
2. This is then passed to the vimwiki#base#resolve_link function (line 482 in html.vim).
3. The resolve_link function then takes the root of source, and then forms the link for index.wiki as C:\Users\user\wiki\foo\bar/../../index.wiki, which is then passed to vimwiki#path#normalize function (line 267 in base.vim),
4. which returns C:\Users\user\wiki\foo\bar/index.wiki, instead of the expected C:\Users\user\wiki\index.wiki

Fix

On line 1646 in html.vim, in the function , we have:

let result = s:convert_file(a:path_html, a:wikifile)

This should be changed to the following:

let result = s:convert_file(a:path_html, vimwiki#path#wikify_path(a:wikifile))

This will pass the path "C:/Users/user/wiki/foo/bar/abc.wiki" instead of "C:\Users\user\wiki\foo\bar\abc.wiki" to convert_file, which will lead to the correct resolution by vimwiki#path#normalize. I have already tested it in the dev branch.

Should I create a pull request for it?

[tinmarino]

Awesome description.
Please, take 1, 2h to write the tests so I don't have to ;-)
I would love all issue to be handked as you did yours

[adi93]

@tinmarino Thanks! First time contributing in open source, so wanted to be thorough. I am not familiar with vadar, so will take 1-2 days looking at existing code base, and will add the test cases by this weekend.

[tinmarino]

Hi @adi93. Still OK to write the tests ? Start by reading the test/Readme.

[adi93]

@tinmarino Yes, working on it. Had some trouble writing the test such that it passes both on Windows and Linux, but have figured it out, and will submit the test in about 3-4 hours.

[tinmarino]

@adi93 I am also currently struggling with the tests. Trying to make the bash script working on Windows.
I have been in all those chroot for 6h advancing slowly. But I can swear that it worth it

[adi93]

Any idea how can I run the tests in windows? So far, what I am stumbling with is this:
I created a file called "command_generate_links.vader " in the test folder, and then I added the following content:

Execute (Goto markdown resource wiki):
    call system('mkdir $HOME/testwiki/')
    edit $HOME/testwiki/abc.wiki
    :write\<CR>

After running ":Vader"

Starting Vader: 1 suite(s), 1 case(s)
  Starting Vader: C:\Users\user\vimfiles\plugged\vimwiki\test\command_generate_links.vader
	(1/1) [EXECUTE] Goto markdown resource wiki
	(1/1) [EXECUTE] (X) Vim(write):E212: Can't open file for writing (<CR>)
	  > C:\Users\user\AppData\Local\Temp\VIEC90F.tmp, line 3
  Success/Total: 0/1
Success/Total: 0/1 (assertions: 0/0)
Elapsed time: 0.11 sec.

The thing is, I can easily run this on WSL, but I want to test it with windows, since that is where the bug comes. Can you point me to an issue that was for windows, and its accompanying tests?

[adi93]

@adi93 I am also currently struggling with the tests. Trying to make the bash script working on Windows.
I have been in all those chroot for 6h advancing slowly. But I can swear that it worth it

Oh, just saw your previous comment.

[tinmarino]

(1/1) [EXECUTE] (X) Vim(write):E212: Can't open file for writing ()
> C:\Users\user\AppData\Local\Temp\VIEC90F.tmp, line 3

Multiple possibilities:

• Try to create a file here and in C:\Users\user\AppData\Local\Temp\
  • Try to open the buffer created with Vader and :w you will get a better complain. Ma
• Include: vader_includes/vader_setup.vader at begining
• your buftype may be nto readable: use set bt= (with nothing) : see the WriteMe helper in vader setup
• watch your environment variables here : bash or vim may be canching its.
  • Try to use gvim
• Turn off antivirus here

Anyway, from :h E212 it seems that some OS stuff below is forbiding you

[adi93]

Anyway, from :h E212 it seems that some OS stuff below is forbiding you

Had no idea that vim had help for these codes as well.

Anyway, your suggestions worked! The problem is, I was confusing the Execute block as a Do block in Vader. Also, writing to C:\Users\user\AppData\Local\Temp\ works. Will add the test tomorrow.

[tinmarino]

Fixed : #945

[tinmarino]

I merged to avoid future conflict.
Fell free to make an other PR for Vader tests: it would be realy apreciated (at long term)