Hugo: Add support for "custom template funcs"

[bep]

I suggest we add support for partials that works like a function.

{{ $calculation := .Arg | strings.Repeat 20 }}
{{ .SetResult  $calculation }}
{{/* or .Fail, .Failf to mark error situations  /*}}

And in a template:

{{ $r := partial "myfuncs/repeat20"  "a" }}
{{ with $r.Error }}
{{ else }}
Letters: {{ $r.Result }}
{{ end }}

We could possibly make this into its own thing (but I fear that we have enough things as it is). We could possibly also support a syntax like this:

{{ $result := customfuncs.Repeat20 "a" }}

The hard part with the above is naming -- and to figure a way to identify these "special partials".

Thoughts?

(note that this is little "me thinking out loud" ... I have some ideas in this department, like anonymous and nested functions.)

[rdwatters]

partialCached
partialFunction

Perhaps partialFunc to be terser.

Or would this add confusion seeing as partialCached is currently under "Functions" in the docs?

W/r/t source organization, will these live in the same partials directory?

Regardless, this seems like a really cool feature and would definitely help with some of the hackery I've personally done in templating.

[regisphilibert]

Discovering this, pretty excited.

It is true, a lot of people, me included, are already using partial to compute numbers or concatenate/generate complex strings rather than simply include or reuse bits of template. But this only means that a need is not being filled. Answering this need by empowering the current partial workaround may, while presently looking consistent, over-complicate the future.

For exemple, in order not to break any existing code, allowing partial to take an argument which is not a map and retrieve it with .Arg should not altere the current behaviour of a context (dict or otherwise) and its keys. Thus on top of making the "Arg" keys reserved would complexity the documentation and the overall usage, especially for people not familiar with the history of partial.

I personally think partial should be left as an "include" solution and a new "thing" should be added.

I also think Hugo's shortcode "API" and its very complete attribute solution (.Get for either named or ordered attrs.) should be the inspiration for this future function function.
New function should only need the .Get method from shortcode plus the .Return method @bep suggested for partial.

Also, and I'm very cautions about this but, I'm not entirely sure an Error handling method is badly needed here for a simple template function. Maybe user could just make its function return nil in case of error?

[bep]

Maybe user could just make its function return nil in case of error?

Just a quick note. We're building this on top of Go's template "engine". There is no return values from a template. So, to return something to the caller, you need to set a value in a object received, e.g. {{ .SetErr "failed"{ }}, or whatever.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[bep]

I'm closing this. I now know how to do this and will start fresh in a new issue.