Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User function w/o argument in templates #181

Closed
Ginner opened this issue Jul 26, 2021 · 4 comments
Closed

User function w/o argument in templates #181

Ginner opened this issue Jul 26, 2021 · 4 comments

Comments

@Ginner
Copy link
Contributor

Ginner commented Jul 26, 2021

Description

I have a template with the following line:

Day:  {{GetDay}}

In my init.vim I have:

function! GetDay() abort
    let l:day_name = strftime("%A")
    return day_name
endfunction

This, however, just result in {{GetDay}} in the new file when using the template.

Workaround

A solution I've found, is to have GetDay take an argument and just give a 'dummy' argument in the template. Like this:
Template file:

Day:    {{GetDay dummyarg}}

init.vim function:

function! GetDay(...) abort
    let l:day_name = strftime("%A")
    return day_name
endfunction

This makes the template behave as intended.

Proposed solution

Am I going about it wrong? Otherwise, I'd suggest one of the following:

  1. Accept function substitutions without arguments.
  2. Allow for adding entries to the context-dictionary (is this already possible?). This could then be used for these small functions without arguments. This might be a good idea regardless.
  3. Describe that an argument is required in the documentation.

My vimscript capabilities are, unfortunately, non-existing. But I'll be happy to take care of option 3 if that's the chosen route.

And again, Karl, I cannot thank you enough for your vim plugins and your continual, non-stop work on them!

lervag added a commit that referenced this issue Jul 26, 2021
@lervag
Copy link
Owner

lervag commented Jul 26, 2021

Thanks for the good description. I've updated this template function feature now to match closely to what you want. Except one thing: the template function must take the context argument as the first argument. Thus, you would need to use either function! GetDay(...) or function! GetDay(ctx) (you can of course ignore the argument).

I believe the updated documentation should be correct according to the updated feature now.

Allow for adding entries to the context-dictionary (is this already possible?). This could then be used for these small functions without arguments. This might be a good idea regardless.

Could you elaborate on this idea some more?

Describe that an argument is required in the documentation.

Please check the update docs; do you find it to be aligned with how you expect it to work now?

And again, Karl, I cannot thank you enough for your vim plugins and your continual, non-stop work on them!

Thanks for the kind words! :)

@lervag lervag closed this as completed Jul 26, 2021
@Ginner
Copy link
Contributor Author

Ginner commented Jul 27, 2021

I've updated this template function feature now to match closely to what you want.

Nice. So if I understand your changes correctly, the function takes the context argument as the first argument instead of taking it as the second argument. Thereby the context argument is given correctly, even if there is no string as the second argument. Is that correct? It is merely my lack of understanding, that caused med to think I could define a function that didn't accept arguments. Looking back, I think it was sufficiently described. But I also think your changes, accepting ctx as the first argument, is better.

Could you elaborate on this idea some more?

Yes. My idea was to make it possible to add your own entries to the context dictionary. So in code it would look something like this:

let l:context += {
    \ 'day_name' = strftime("%A"),
    \}

Allowing me to use {day_name} as variable substitution, in addition to the already available date, time, etc. However, I think it should be made available as a setting in $MYVIMRC. E.g.:

let g:wiki_template_context = {
    \ 'name': 'John Doe',
    \ 'day_name': strftime("%A"),
    \ 'user': system("whoami"),
    \ }

These could easily be created as user defined substitution-functions, but I think it would be nice to gather these 'non-argument' variables in the context dictionary.

Please check the update docs; do you find it to be aligned with how you expect it to work now?

Yes, it looks good. At least I think I understand it know ;) However, I expanded a little on the substitution function, by providing the predefined function as an example. Please see pull request #182.

@lervag
Copy link
Owner

lervag commented Jul 27, 2021

Nice. So if I understand your changes correctly, the function takes the context argument as the first argument instead of taking it as the second argument. Thereby the context argument is given correctly, even if there is no string as the second argument. Is that correct? It is merely my lack of understanding, that caused med to think I could define a function that didn't accept arguments. Looking back, I think it was sufficiently described. But I also think your changes, accepting ctx as the first argument, is better.

Yes, exactly. It makes more sense this way, and it makes it easy to allow the second argument to be optional.

Could you elaborate on this idea some more?

Yes. My idea was to make it possible to add your own entries to the context dictionary. So in code it would look something like this: ...

Ah, I see. Would you mind opening a new issue for this? That would make it easier for me to quickly get up to context when I have time to fully consider it.

Please check the update docs; do you find it to be aligned with how you expect it to work now?

Yes, it looks good. At least I think I understand it know ;) However, I expanded a little on the substitution function, by providing the predefined function as an example. Please see pull request #182.

Great, thanks!

@Ginner
Copy link
Contributor Author

Ginner commented Jul 29, 2021

Nice! I've finally opened a new issue describing the functionality requested. See #184.

Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants