origin_lnum in context dictionary not working

[Ginner]

Description

The context dictionary for the templates functionality returns 1 for origin_lnum .

Expected behaviour:
In my template, for a given case, {origin_lnum} is expected to return 146, as the wiki link is at line 146. However it returns 1.

Looking at the context dictionary and the function wiki#nav/get_previous() I don't see how it could return anything else than 1:

autoload/wiki/template.vim:

let l:origin = wiki#nav#get_previous()

let l:context = {
        ...
        \ 'origin_lnum': l:origin[1][1],
        ...
        \}

autoload/wiki/nav.vim:

function! wiki#nav#get_previous() abort "{{{1
  let l:previous = get(s:position_stack, -1, [])
  if !empty(l:previous) | return l:previous | endif

  let l:file = expand('#:p')
  let l:pos = [0, 1, 1, 0, 1]                                      <------ Namely this line
  if filereadable(l:file) | return [l:file, l:pos] | endif

  return ['', l:pos]
endfunction

[lervag]

Ah, the origin position is something else. I can understand the confusion! The origin position is the last position before you follow/open a link. It is updated with wiki#nav#add_to_stack, and the position returned with get_previous is just to ensure you get something that is not totally unreasonable.

[Ginner]

Hmm... I'm not sure I understand. What does the number returned by ctx.origin_lnum represent? (123 in the doc example)

I believe the wiki#nav#add_to_stack is for navigating with e.g. <bs>, right? Are the number a reference to a sort of 'navigation stack'?

[lervag]

Yes, exactly. If you open say index.wiki, then follow a link on line 10 to foobar.wiki, then index.wiki line number 10 is added to the navigation stack. The relevant code is here:

wiki.vim/autoload/wiki/url/wiki.vim

Line 98 in 24d969a

call wiki#nav#add_to_stack(l:old_position)

However: I realize it is probably better to insert the actual link object to the stack. It will potentially give much more relevant information. I'm making this change now.

[lervag]

Ok, I've made the changes now. The origin entry in the context dictionary is now a copy of the original link/url object. This gives much more flexibility for those who need/want it. I've also tried to add enough documentation to make it easy to use for a similar purpose as the previous version.

[Ginner]

I think it is nice to have those(origin, pos_start and curpos) in the context dictionary. However, having it as a dict means that the context-dictionary, in the case of the origin top level key has to be manipulated in a user-defined substitution function. Is that right? I.e. what happens if I use {origin} in a template? Can I use {origin.origin} or {origin["origin"]}?

I like the idea of the context-dictionary returning simple strings for the variable substitution and user- and pre-defined functions for everything else. But that's merely an opinion.

I'm sorry, but I haven't been able to test the above, as I cannot get the template functionality to work. It might be on my end though? I've cut away all my user defined functions in my .vimrc and only have the following:

let g:wiki_templates            = [
      \ {'match_re': '^test$',
      \   'source_filename': $HOME .. '/Documents/wiki/templates/test_template.md'},
      \ ]

With test_template.md looking like this:

# {name}

and a link like [test](test.md) doesn't activate it anymore. Unless it doesn't work on your end, I'll try and debug my setup further and maybe file it as a new issue.

[lervag]

I think it is nice to have those(origin, pos_start and curpos) in the context dictionary. However, having it as a dict means that the context-dictionary, in the case of the origin top level key has to be manipulated in a user-defined substitution function. Is that right?

Yes. Good point!

I.e. what happens if I use {origin} in a template? Can I use {origin.origin} or {origin["origin"]}?

No, this is currently not possible. But I agree it makes sense to add something like this. Not sure what is the best solution, but I do like the {origin.key} variant.

I like the idea of the context-dictionary returning simple strings for the variable substitution and user- and pre-defined functions for everything else. But that's merely an opinion.

I want the context dictionary to "work the same" everywhere. And I believe it should work quite well with the dot notation as discussed above. Or am I wrong?

I'm sorry, but I haven't been able to test the above, as I cannot get the template functionality to work. It might be on my end though?

There was an error that I believe is fixed now. Can you please test again? I've also implemented the above mentioned dot notation so that should now work as expected.

[Ginner]

I like the idea of the context-dictionary returning simple strings for the variable substitution and user- and pre-defined functions for everything else. But that's merely an opinion.

I want the context dictionary to "work the same" everywhere. And I believe it should work quite well with the dot notation as discussed above. Or am I wrong?

You're not wrong, I also think the dot notation works well. I do think the context dictionary would be a little 'cleaner' with origin, post_start and curpos as top-level keys, and then not having it contain a dictionary, but only return single strings. However, I'm being extremely nitpicky. And I think I do see value in 'opening' to possibility of the context-dictionary returning dictionaries and thereby segmenting it a little - that might prove valuable if it grows further.

I think it works well as it is now, I only intend to exhaust the possibilities. Please ignore and leave as is, if you don't find it relevant.

There was an error that I believe is fixed now. Can you please test again?

It works flawlessly now, as far as I can tell. Thank you!

[Ginner]

I do think the context dictionary would be a little 'cleaner' with origin, post_start and curpos as top-level keys, and then not having it contain a dictionary, but only return single strings.

Oh my god, I realize now that, that is pretty much the way it was, before I started yapping. Please excuse me and proceed in any way you see fit.

[lervag]

It works flawlessly now, as far as I can tell. Thank you!

Happy to hear it!

You're not wrong, I also think the dot notation works well. I do think the context dictionary would be a little 'cleaner' with origin, post_start and curpos as top-level keys, and then not having it contain a dictionary, but only return single strings. However, I'm being extremely nitpicky. And I think I do see value in 'opening' to possibility of the context-dictionary returning dictionaries and thereby segmenting it a little - that might prove valuable if it grows further.

...

Oh my god, I realize now that, that is pretty much the way it was, before I started yapping. Please excuse me and proceed in any way you see fit.

Well, not really. The old version was less consistent. The new version reliably gives a dictionary with the origin link object, regardless of what the origin is. In some cases, there is no origin (e.g. if you do :edit new.md), whereas in other cases, the origin is only an URL and not a "physical" link (e.g. if you use :WikiOpen). However, when you follow a link, then the origin will contain all of the available metadata of that particular link. I believe that the keys origin, pos_start, and curpos are the most interesting data, but at least now the user does get access to everything.

In any case, I'm glad to hear you find this suitably resolved now. Feel free to suggest improvements to the docs, raise new issues, or raise new feature suggestions!