taking (w, h int).

R=rsc, bsiegert, r
CC=golang-dev
https://golang.org/cl/4964073

Fixes #2181.

R=golang-dev, jp
CC=golang-dev
https://golang.org/cl/5000042

The template package is the only one that has a doc.go not mentioned
in its Makefile.

This doesn't seem to bother godoc, but seems like a bug to me.

$ for d in $(find pkg -name doc.go); do echo $d; grep doc.go $(dirname $d)/Makefile; done
pkg/fmt/doc.go
        doc.go\
pkg/go/doc/doc.go
        doc.go\
pkg/gob/doc.go
        doc.go\
pkg/html/doc.go
        doc.go\
pkg/old/template/doc.go
        doc.go\
pkg/sync/atomic/doc.go
        doc.go\
pkg/template/doc.go

R=r
CC=golang-dev
https://golang.org/cl/5003047

This CL moves code but makes no changes otherwise.

R=nigeltao, r
CC=golang-dev
https://golang.org/cl/5012045

This one uses a closure than an interface, and is much simpler to use.
It also enables a called function to return an error and (possibly)
halt processing.

Fixes #2237.

R=golang-dev, gri, rsc, r, cw, n13m3y3r
CC=golang-dev
https://golang.org/cl/5014043

This adds support for {{template "callee"}} calls.
It recognizes that calls can appear in many contexts.

{{if .ImageURL}}
    <img src="{{.ImageURL}}" alt="{{template "description"}}">
{{else}}
    <p>{{template "description"}}</p>
{{end}}

calls a template in two different contexts, first in an HTML attribute
context, and second in an HTML text context.

Those two contexts aren't very different, but when linking text
to search terms, the escaping context can be materially different:

<a href="/search?q={{template "tags"}}">{{template "tags"}}</a>

This adds API:
EscapeSet(*template.Set, names ...string) os.Error

takes a set of templates and the names of those which might be called
in the default context as starting points.

It changes the escape* functions to be methods of an object which
maintains a conceptual mapping of
(template names*input context) -> output context.

The actual mapping uses as key a mangled name which combines the
template name with the input context.

The mangled name when the input context is the default context is the
same as the unmangled name.

When a template is called in multiple contexts, we clone the template.

{{define "tagLink"}}
  <a href="/search?q={{template "tags"}}">{{template "tags"}}</a>
{{end}}
{{define "tags"}}
  {{range .Tags}}{{.}},{{end}}
{{end}}

given []string{ "foo", "O'Reilly", "bar" } produces

  <a href="/search?q=foo,O%27Reilly,bar">foo,O&#39;Reilly,bar</a>

This involves rewriting the above to something like

{{define "tagLink"}}
  <a href="/search?q={{template "tags$1"}}">{{template "tags"}}</a>
{{end}}
{{define "tags"}}
  {{range .Tags}}{{. | html}},{{end}}
{{end}}
{{define "tags$1"}}
  {{range .Tags}}{{. | urlquery}},{{end}}
{{end}}

clone.go provides a mechanism for cloning template "tags" to produce
"tags$1".

changes to escape.go implement the new API and context propagation
around the call graph.

context.go includes minor changes to support name mangling and
context_test.go tests those.

js.go contains a bug-fix.

R=nigeltao, r
CC=golang-dev
https://golang.org/cl/4969072

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5002043

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/5013042

R=r
CC=golang-dev
https://golang.org/cl/4973064

This CL only supports Unix, not Plan 9 or Windows.

R=rsc
CC=golang-dev
https://golang.org/cl/4996048

R=bradfitz
CC=golang-dev
https://golang.org/cl/4967067

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4983060

Often, division/regexp ambiguity doesn't matter in JS because the next
token is not a slash.

For example, in

  <script>var global{{if .InitVal}} = {{.InitVal}}{{end}}</script>

When there is an initial value, the {{if}} ends with jsCtxDivOp
since a '/' following {{.InitVal}} would be a division operator.
When there is none, the empty {{else}} branch ends with jsCtxRegexp
since a '/' would start a regular expression.  A '/' could result
in a valid program if it were on a new line to allow semicolon
insertion to terminate the VarDeclaration.

There is no '/' though, so we can ignore the ambiguity.

There are cases where a missing semi can result in ambiguity that
we should report.

  <script>
  {{if .X}}var x = {{.X}}{{end}}
  /...{{.Y}}
  </script>

where ... could be /foo/.test(bar) or /divisor.  Disambiguating in
this case is hard and is required to sanitize {{.Y}}.

Note, that in the case where there is a '/' in the script tail but it
is not followed by any interpolation, we already don't care.  So we
are already tolerant of

<script>{{if .X}}var x = {{.X}}{{end}}/a-bunch-of-text</script>

because tJS checks for </script> before looking in /a-bunch-of-text.

This CL
- Adds a jsCtx value: jsCtxUnknown
- Changes joinContext to join contexts that only differ by jsCtx.
- Changes tJS to return an error when a '/' is seen in jsCtxUnknown.
- Adds tests for both the happy and sad cases.

R=nigeltao
CC=golang-dev
https://golang.org/cl/4956077

Similar tests for CSS already catch this problem in tCSS.

R=nigeltao
CC=golang-dev
https://golang.org/cl/4967065

Fixes #2253.

R=agl
CC=golang-dev
https://golang.org/cl/4960066

Fixes #2248.

R=ken2
CC=golang-dev
https://golang.org/cl/4978064

This makes it possible to grab a block of code
in an editor and pipe it through gofmt, instead of
having to pipe in the entire file.

R=gri
CC=golang-dev
https://golang.org/cl/4973074

R=rsc
CC=golang-dev
https://golang.org/cl/4983058

The path is not in fact relative to the root, but
joined to it.

R=golang-dev, adg, rsc, gustavo
CC=golang-dev
https://golang.org/cl/4977059

Weekday is redundant information for a Time structure.
When parsing a time with a weekday specified, it can create an
incorrect Time value.
When parsing a time without a weekday specified, people
expect the weekday to be set.
Fix all three problems by computing the weekday on demand.

This is hard to gofix, since we must change the type of the node.
Since uses are rare and existing code will be caught by the compiler,
there is no gofix module here.

Fixes #2245.

R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/4974077

Reported by Kyle Lemons.

R=r
CC=golang-dev
https://golang.org/cl/4992045

String() is already inherited from the embedded *url.URL

R=ukai, adg, rsc
CC=golang-dev
https://golang.org/cl/4992049

as this part of Hangul is handled algorithmically.

R=r
CC=golang-dev
https://golang.org/cl/4951074

R=dsymonds
CC=golang-dev, mikesamuel
https://golang.org/cl/4972063

decoding during an init function.

Fixes #2224.

R=rsc
CC=golang-dev
https://golang.org/cl/4964070

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/4996041

Fixes #2241
while not breaking issue 1878 again.

R=rsc
CC=golang-dev
https://golang.org/cl/4988048

Fixes #2201

R=golang-dev, r, rsc, alex.brainman, robert.hencke, jp
CC=golang-dev
https://golang.org/cl/4950051

Augments type context and adds grammatical rules to handle special HTML constructs:
    <!-- comments -->
    <script>raw text</script>
    <textarea>no tags here</textarea>

This CL does not elide comment content.  I recommend we do that but
have not done it in this CL.

I used a codesearch tool over a codebase in another template language.

Based on the below I think we should definitely recognize
  <script>, <style>, <textarea>, and <title>
as each of these appears frequently enough that there are few
template using apps that do not use most of them.

Of the other special tags,
  <xmp>, <noscript>
are used but infrequently, and
  <noframe> and friend, <listing>
do not appear at all.

We could support <xmp> even though it is obsolete in HTML5
because we already have the machinery, but I suggest we do not
support noscript since it is a normal tag in some browser
configurations.

I suggest recognizing and eliding <!-- comments -->
(but not escaping text spans) as they are widely used to
embed comments in template source.  Not eliding them increases
the size of content sent over the network, and risks leaking
code and project internal details.
The template language I tested elides them so there are
no instance of IE conditional compilation directives in the
codebase but that could be a source of confusion.

The codesearch does the equivalent of
$ find . -name \*.file-extension \
  | perl -ne 'print "\L$1\n" while s@<([a-z][a-z0-9])@@i' \
  | sort | uniq -c | sort

The 5 uses of <plaintext> seem to be in tricky code and can be ignored.
The 2 uses of <xmp> appear in the same tricky code and can be ignored.
I also ignored end tags to avoid biasing against unary
elements and threw out some nonsense names since since the
long tail is dominated by uses of < as a comparison operator
in the template languages expression language.

I have added asterisks next to abnormal elements.

  26765 div
   7432 span
   7414 td
   4233 a
   3730 tr
   3238 input
   2102 br
   1756 li
   1755 img
   1674 table
   1388 p
   1311 th
   1064 option
    992 b
    891 label
    714 script *
    519 ul
    446 tbody
    412 button
    381 form
    377 h2
    358 select
    353 strong
    318 h3
    314 body
    303 html
    266 link
    262 textarea *
    261 head
    258 meta
    225 title *
    189 h1
    176 col
    156 style *
    151 hr
    119 iframe
    103 h4
    101 pre
    100 dt
     98 thead
     90 dd
     83 map
     80 i
     69 object
     66 ol
     65 em
     60 param
     60 font
     57 fieldset
     51 string
     51 field
     51 center
     44 bidi
     37 kbd
     35 legend
     30 nobr
     29 dl
     28 var
     26 small
     21 cite
     21 base
     20 embed
     19 colgroup
     12 u
     12 canvas
     10 sup
     10 rect
     10 optgroup
     10 noscript *
      9 wbr
      9 blockquote
      8 tfoot
      8 code
      8 caption
      8 abbr
      7 msg
      6 tt
      6 text
      6 h5
      5 svg
      5 plaintext *
      5 article
      4 shortquote
      4 number
      4 menu
      4 ins
      3 progress
      3 header
      3 content
      3 bool
      3 audio
      3 attribute
      3 acronym
      2 xmp *
      2 overwrite
      2 objects
      2 nobreak
      2 metadata
      2 description
      2 datasource
      2 category
      2 action

R=nigeltao
CC=golang-dev
https://golang.org/cl/4964045

R=r, adg
CC=golang-dev
https://golang.org/cl/4995041

R=alex.brainman
CC=golang-dev
https://golang.org/cl/4983053

Also: fix layout of textual search results and
fix a field reference in the respective template.

Fixes #1987.

R=rsc, r
CC=golang-dev
https://golang.org/cl/4962061

This does not wire up <style> elements as that is pending support
for raw text content in CL https://golang.org/cl/4964045/

This CL allows actions to appear in contexts like

selectors:        {{.Tag}}{{.Class}}{{.Id}}
property names:   border-{{.BidiLeadingEdge}}
property values:  color: {{.Color}}
strings:          font-family: "{{font-name}}"
URL strings:      background: "/foo?image={{.ImgQuery}}"
URL literals:     background: url("{{.Image}}")

but disallows actions inside CSS comments and disallows
embedding of JS in CSS entirely.

It is based on the CSS3 lexical grammar with affordances for
common browser extensions including line comments.

R=nigeltao
CC=golang-dev
https://golang.org/cl/4968058

R=r
CC=golang-dev
https://golang.org/cl/4962060

R=r
CC=golang-dev
https://golang.org/cl/4967060

R=r
CC=golang-dev
https://golang.org/cl/4952061

R=golang-dev
CC=golang-dev
https://golang.org/cl/4956069

- fix suggested by rodrigo.moraes

Fixes #1755.

R=rsc
CC=golang-dev
https://golang.org/cl/4977057

Not exposed in the API yet, but passes tests.

R=r
CC=golang-dev
https://golang.org/cl/4967059

R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/4969063