text/template: no nice way to escape/suppress newlines

[eloff]

In many text/template scenarios, when creating text files (e.g. csv) for machine consumption, or text documents for human consumption, it's desirable to control the newlines output by the template. Currently this involves jumping through hoops by moving template tags around, making the template very unreadable. A simple e.g \ character at the end of a line would be nice to escape the newline so it doesn't end up in the output text, but the template tags can still be organized nicely in the template itself.

Seems there was already a request for this on go-nuts: https://groups.google.com/forum/#!topic/golang-nuts/H_d6P6av8nk

[adg]

However this might work, it would need to be backward-compatible with existing templates. That rules out \ at the end of a line.

[eloff]

Good point. How about nunjucks system of adding a - at the start and/or end of a block to eat leading/trailing whitespace? Nunjucks does that: http://mozilla.github.io/nunjucks/templating.html#whitespace-control

{{range .foos -}} // eats trailing whitespace
{{.}}
{{-end}} // eats leading whitespace (\n from previous line)

[adg]

Seems like a reasonable approach. Can you give me an example of where this might help, so that I can judge the feature in context?

[eloff]

Sure, the thread had an example of generating a tsv file I think, but my
use case is generating program code. I end up with a lot of empty lines
where I had control tags, range tags, if tags, etc.

so I have something that looks like:

{{with .BitShift}}
    {{if ne . 0}}val >>= {{ . }}{{end}}
{{end}}

{{with $mask := .BitMask}}
{{if ne $mask 0 }}val &= 0x{{ printf "%x" $mask }}{{end}}
{{if ne $mask 0 | and $.IsSigned }}
val = val<<63 | val>>1
{{end}}
{{end}}

Which produces a lot of empty lines. I have to put non-related things on
the same line, make very long lines, etc to get the formatting I want. With
some whitespace eating feature I could do:

{{with .BitShift-}} // eats the newline and the indentation on the next

line
{{if ne . 0}}val >>= {{ . }}{{end}}
{{end-}}
{{with $mask := .BitMask-}}
{{if ne $mask 0 }}val &= 0x{{ printf "%x" $mask }}{{end}}
{{if ne $mask 0 | and $.IsSigned -}}
val = val<<63 | val>>1
{{end-}}
{{end-}}

Not sure if the dash character is the best choice, but something like that
to suppress newlines and indentation before or after tags would do the
trick.

On Mon, Feb 23, 2015 at 10:12 PM, Andrew Gerrand notifications@github.com
wrote:

Seems like a reasonable approach. Can you give me an example of where this
might help, so that I can judge the feature in context?

—
Reply to this email directly or view it on GitHub
#9969 (comment).

[josharian]

I've also frequently run into this while generating code and been frustrated by it. go/format can take care of multiple newlines, but it never goes from one newline to zero.

[adg]

The current way to avoid a newline is to do this:

Some text without a {{/*
*/}}newline in the middle.

which is a little verbose for such a minor signal. It would be helpful to have some way to signal that we don't want a newline.

1. Do we want the signal to be part of existing actions? (As in, {{end FOO}} where FOO is some token that doesn't collide with the current syntax.) Or, should "no new line" be an action of its own? ({{FOO}} for example) The former has the benefit of brevity, the latter has the benefit of being unambiguous and is probably cleaner to implement
2. Regardless of the answer to question 1, what should FOO be? A dash (-) is one idea, but there are many other things we can use. Back slash (\) seems more natural to me.

Some text without a {{\}}
newline in the middle.

A list of items:
{{range .Items \}}
{{.}} {{end}}

Should produce (where Items is [1,2,3,4]):

Some text without a newline in the middle.

A list of items:
1 2 3 4 

Hey @robpike what do you think?

[minux]

Could we add some kind of pre-template configuration options? {{ option +line-continuation }} or something like that. and then we can just use the most natural syntax for line continuation: line 1 \ line 2 It also preserves compatibility with existing templates. we can also make the line continuation character (or character sequence) configurable.

[eloff]

Or it can be a method on template, e.g.
template.New(...).WithLineEscapes().Parse(...)

On Tue, Feb 24, 2015 at 7:32 PM, Minux Ma notifications@github.com wrote:

Could we add some kind of pre-template configuration options?
{{ option +line-continuation }}
or something like that.

and then we can just use the most natural syntax for line continuation:
line 1
line 2

It also preserves compatibility with existing templates.

we can also make the line continuation character (or character sequence)
configurable.

—
Reply to this email directly or view it on GitHub
#9969 (comment).

[minux]

I don't propose it to be a method on Template is because I think this configuration is better contained in the template file itself, so that the code that uses the template doesn't need to know whether the template uses that feature or not. I will also seamlessly update existing code and templates. Just recompile the code with Go 1.5 and you can start using this feature in templates.

[dworld]

I expect it as a builtin function, for example.

now:

        {{ range .Route }}
            {{ if contains .Method "GET" }} server.Get("{{.Path}}", {{$prefix}}do{{.Name}}{{$suffix}})
            {{end}} {{ if contains .Method "POST" }} server.Post("{{.Path}}", {{$prefix}}do{{.Name}}{{$suffix}}) {{end}}  {{ end }}

use a builtin functin EAT_NEXT_NEWLINE:

        {{ range .Route }}
            {{ if contains .Method "GET" }} server.Get("{{.Path}}", {{$prefix}}do{{.Name}}{{$suffix}}) {{ EAT_NEXT_NEWLINE }} {{ end }} {{ end }}
            {{ if contains .Method "POST" }} server.Get("{{.Path}}", {{$prefix}}do{{.Name}}{{$suffix}}) {{ end }} {{ EAT_NEXT_NEWLINE }} 
        {{ end }}

[cespare]

I run into this almost every time I use */template. I just did today: I was generating big SQL prepared statements using text/template and I had to choose between making the template easy-to-read and making the generated statement easy-to-read.

[sayeed-anjum]

I am using consul-template to generate text config files using a Go template. The templates can get quite complicated with nested ranges and conditionals. Making output result readable leads to ugly and unreadable code. Needs to be fixed at the earliest.

[loa]

+1

[zeevallin]

I'm also generating configuration which at some point will need to be read by humans. I really like the idea of {{- end }} for leading whitespace and {{ end -}} for trailing. +1