I don't still understand why this fix #421. please explain.

For this example, I have a test file named test.cpp located in D:\tmp. Its contents are as follows:

int x;

Running Exuberant Ctags 5.8 on this file with the appropriate options, as defined in buffertag.vim, yields the following (omitting the header):

x	D:\tmp\test.cpp	/^int x;$/;"	variable	line:1

Running Universal Ctags on this file (I used the 2018-07-18 release) yields:

x	D:\\tmp\\test.cpp	/^int x;$/;"	variable	line:1

Note the double backslashes in the file name.

These lines are parsed in the s:parseline() function of buffertag.vim. Of particular note in this function is line 208:

let [bufnr, bufname] = [bufnr('^'.vals[2].'$'), fnamemodify(vals[2], ':p:t')]

where vals[2] is the matched filename.

Note the call to bufnr(). Running bufnr('^'.vals[2].'$') for our Exuberant Ctags example would be equivalent to bufnr('^'.'D:\tmp\test.cpp'.'$'). This will result in a valid buffer number, such as 13.

For the Universal Ctags case, the equivalent call would be bufnr('^'.'D:\\tmp\\test.cpp'.'$') and this will always result in the error value -1. This is due to the double backslashes in the filename. The failing bufnr() call breaks the entire buffer tag functionality.

As I mentioned before, my solution is to replace double backslashes with single forward slashes. So for our example, the Universal Ctags filename would be modified to D:/tmp/test.cpp which will result in a successful bufnr() call.