qqzsxyz / vimwiki

Automatically exported from code.google.com/p/vimwiki
0 stars 0 forks source link

Directory indexes broken #283

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

1. Configure vimwiki to open netrw for directory links, using 

 let g:vimwiki_dir_link=''

2. Add a directory link to a vimwiki page

 [[dir/]]

3. Follow the link

What is the expected output? What do you see instead?

This used to give a netrw view of the dir/ directory, but now I get

 "~\vimwiki\dir\" Illegal file name

Swiching to another vim window or tab and then going back to the vimwiki window 
will eventually show the netrw view.

To reproduce:

1. open Vim
2. vnew to split the viewport
3. open vimwiki in one of the windows
4. follow a [[dir/]] link

this will give you an empty buffer and the error above

5. move to the other window (e.g., with Ctrl-W P)
6. move back to the vimwiki windows

the netrw view will now appear.

What version of the product are you using? On what operating system?

Vim 7.3 with VimWiki 1.2, on both windows and linux. I can also reproduce the 
issue with the latest source, and with clean .vimrc and .vim/ directory.

Original issue reported on code.google.com by dreadnaut on 23 Feb 2012 at 4:04

GoogleCodeExporter commented 8 years ago
I am experiencing similar behavior with the development version but have not 
been able to figure out what is causing it.  My temporary solution is to run 
":e<CR>", but that is not ideal

Original comment by stu.andrews on 24 Feb 2012 at 2:22

GoogleCodeExporter commented 8 years ago
I used _hg bisect_ to search for the first revision which causes the problem. I 
tested each revision manually, as such:

1. open gvim with --cmd "set runtimepath=vimwiki/src,<vim directory>"
2. open vimwiki index using <leader>ww
3. open the [todo/] link I have in the index
4. mark the revision as good if I get the netrw buffer, bad otherwise

Note that even good revisions showed the "Illegal file name" error, together 
with the netrw buffer.

hg bisect lead me to this changeset:

The first bad revision is:
changeset:   183:43dcaa06d159
user:        Maxim Kim <habamax@gmail.com>
date:        Thu Dec 02 21:14:17 2010 +0300
summary:     * Issue 117: |VimwikiDiaryIndex| command that opens diary index 
wiki page.

http://code.google.com/p/vimwiki/source/detail?r=43dcaa06d159fc82cc5980bc828f40a
4362d5e7d

Original comment by dreadnaut on 24 Feb 2012 at 1:52

GoogleCodeExporter commented 8 years ago
Thanks for the hg-bisect trick!  

Habamax introduced a try-statement in revision 43dcaa06d159.  However, Netrw 
runs into difficulty when the ":e <DIR>" command is evaluated *inside a 
try-catch* statement.  See: 
http://vim.1045645.n5.nabble.com/netrw-in-try-clause-td3375542.html

Perhaps the try-stmt inside edit_file() can be eliminated.  First, given that 
autowriteall is set in ftplugin/vimwiki.vim, I don't believe that edit_file()  
will ever catch 'No write since last change' Error /E37/ . 

Secondly, *NOT* catching E325 ".FILE.swp exists" might be okay.  

Thoughts?

I'm experimenting with a simpler version of edit_file() that looks like this:

  let fname = escape(a:filename, '% ')
  call vimwiki#base#mkdir(fnamemodify(a:filename, ":p:h"))
  execute a:command.' '.fname

Original comment by stu.andrews on 27 Feb 2012 at 6:07

GoogleCodeExporter commented 8 years ago
Sure, we can assume /E37/ would never appear, I believe there are not so many 
vimwiki users who sets their modelines to noautowriteall.

As for E325 - I have added it to remove 'red errors' produced by open_link. If 
it doesn't bother anyone but me, we can drop it too.

Original comment by habamax on 27 Feb 2012 at 6:40

GoogleCodeExporter commented 8 years ago
I have tested your simple version of edit_file() and it looks OK.

Original comment by habamax on 1 Mar 2012 at 6:06