qqzsxyz / vimwiki

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

Following local wiki links in subdirectories sometimes breaks (tip) #300

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I have a number of pages that have live in their own directories. For example:

== Projects ==
* [[Projects/Do something interesting]]
* [[Projects/Do something else]]
* [[Projects/Whatever]]
* [[Something Random]]

This has worked fine up until recently. Most of the time this continues to work 
fine.

However, if, for example, I Shift+Enter on a link, opening it in a horizontal 
split, then any time I try to open another link, it assumes that the next link 
is inside the previous link's directory.

Let's say I shift+Enter on "Projects/Do something interesting". The Then I 
close the window (:q) and try to open "Projects/Do something else", it will 
assume that "Projects/Do something else" is INSIDE a directory "Projects" 
(Projects/Projects/Do something else), prompting me to create the directory 
"Projects" inside of the existing "Projects". If I clicked on "Something 
Random", it will try to open "Something Random" from inside the "Projects" 
directory, which obviously doesn't exist, so I get a blank document.

I've bisected the revision which introduced the breakage to:
changeset:   511:8ef36f2bb0c8
user:        Stuart Andrews <stu.andrews@gmail.com>
date:        Mon Mar 26 15:35:04 2012 -0400
summary:     RM pageload in VimwikiAll2HTML. RM wiki: scheme w/o #. Per-buffer 
state cachin

I'm running tip (b8abc7890795) on vim 7.3.492 on Windows (GVim)

Original issue reported on code.google.com by abat...@gmail.com on 10 Apr 2012 at 8:27

GoogleCodeExporter commented 8 years ago
Interesting!  I will have to learn more about buffer variables in horizontally 
split windows.  For an immediate and temporary fix you can type ":e<CR>" to 
reset the buffer's state ...

Original comment by stu.andrews on 10 Apr 2012 at 10:45

GoogleCodeExporter commented 8 years ago
At about the same time, opening (from a file manager, not when Vim is already 
running) "an orphan" stopped working (Vim simply freezes on startup). But I am 
not sure it happens with every orphan, and I have not checked the most recent 
version yet.

Original comment by tpospi...@gmail.com on 11 Apr 2012 at 7:30

GoogleCodeExporter commented 8 years ago
Please try r357ea97ada16.  Thanks!

Original comment by stu.andrews on 13 Apr 2012 at 4:42

GoogleCodeExporter commented 8 years ago
@tpospich8: I think I have tracked down the cause of the failure for "orphan" 
wikis.  Back in r491, you added code inside setup_filetype() to partially 
initialize the wiki state, even when idx == -1:

  "XXX when idx = -1?
  let g:vimwiki_current_idx = idx
  let b:vimwiki_idx = idx

However, upon subsequent BufWinEnter, the setup_buffer_enter() function was 
prevented from creating a temporary wiki for the orphan file because 
b:vimwiki_idx has already been defined.

  if exists("b:vimwiki_idx")
    let g:vimwiki_current_idx = b:vimwiki_idx
  else
    ... snip ...
    if idx == -1
      call add(g:vimwiki_list, {'path': path, 'ext': ext, 'temp': 1})
      let g:vimwiki_current_idx = len(g:vimwiki_list) - 1
    else
      let g:vimwiki_current_idx = idx
    endif
    let b:vimwiki_idx = g:vimwiki_current_idx
  endif

In my testing, the orphan page is partially functional (syntax highlighting 
appears to work), although the temporary orphan wiki is not created.

Now, fast forward to the present.  When I added per-buffer caching of the wiki 
state in r511, I assumed that b:vimwiki_idx would always refer to a valid wiki 
idx.  Since -1 is invalid, Vimwiki gets stuck somewhere inside 
setup_buffer_enter() > recall_wiki_state() ... or so it seems. 

I am now considering ways to solve this problem.  In one solution, I have 
copied the code (that initializes the orphan wiki) from setup_buffer_enter() 
and put it inside setup_filetype().  This seems redundant, so I am looking for 
an alternative.

I would like to understand why you added the initialization of b:vimwiki_idx 
inside setup_filetype().  Do you need to access to the per-wiki options after a 
BufNewFile or BufRead event, but before a BufWinEnter event?  

If you have a chance, please take a look and let me know.
Thanks, 
- S.

Original comment by stu.andrews on 17 Apr 2012 at 8:57

GoogleCodeExporter commented 8 years ago
Stu, I have tried to open tests/wiki/index.wiki and then follow any link inside 
it with no luck. Is this because of orphan wiki is not created anymore?

Original comment by habamax on 27 Apr 2012 at 11:19

GoogleCodeExporter commented 8 years ago
The original issue seems to be fixed.

Original comment by habamax on 9 May 2012 at 2:03