Bump on this.

I wrote a codewalk XML, before reading the how-to-write-codewalks part and realized that it only works for $GOROOT.

Felt like a gut punch.

OK I'm irritated enough I'm willing to take a stab at this. How's this for a plan:

1. walk the $GOPATH and find codewalk.xml (each of has src which points within the $GOPATH
2. Display the listing in XXX/doc/codewalk/pkg
3. Populate things necessary in *Presentation such that the codewalk.html template can be populated

I think it would be preferable to show them under pkg/ itself (say, github.com/user/repo/codewalk.html or something), as that would allow to show them on godoc.org too.

Does introducing a format other than XML fall under the scope of making the codewalks more accessible from an author perspective?

I took a stab at it. It wasn't difficult.

Here's how it looks like:

Some considerations: the code right now scans for multiple codewalk_*.xml and codewalk.xml. I found that I can't get multiple codewalk.xml working due to codewalk.js relying on #codewalk-main. I'm too lazy to mess with JavaScript.

The endpoint is DOMAIN/codewalk/.... Before I proceed further with working on listing the codewalks, I think it might be a good idea to discuss this further.

Waiting comments from the Go team in particular

Please send a CL.

Some considerations: the code right now scans for multiple codewalk_*.xml and codewalk.xml. I found that I can't get multiple codewalk.xml working due to codewalk.js relying on #codewalk-main. I'm too lazy to mess with JavaScript.

Can you expand on this? I don't understand the second sentence.

The endpoint is DOMAIN/codewalk/.... Before I proceed further with working on listing the codewalks, I think it might be a good idea to discuss this further.

It seems more natural to me that these should be

/doc/codewalk/package_path

where package_path is something like github.com/chewxy/repo/codewalk, where the file is github.com/chewxy/repo/codewalk.xml.

Then they can be listed in /doc/codewalk/ as well.

So the current codewalk.js works by finding #codewalk-main and then updating the elements.

I have this in the template (call this codewalk2.html):

{{ range $ := .Codewalks }}
{{/* the template here is copied from the current codewalk.html template */}}
{{end}}

If there is only one codewalk.xml it's fine. But if there are two (codewalk.xml and codewalk_2.xml), then the JavaScript bits start acting weird - only the first code walk will get interactivity. I inspected the JS but then I was too sleepy last night to work on it further.

Will send a CL when this is more complete.

@adg Just to double check on the structure of the program, before I go ahead this weekend and implement it fully.

Should I implement/augment the codewalk handler in golang.org/x/tools/cmd/godoc or should I continue with my hack and implement it within the golang.org/x/tools/godoc.Presentation?

@chewxy it's been a while since I looked at the code. Maybe just send out what you've got and I can help you iterate on the design from there?

yep ok. I've not actually started on it. Will do soon

Obviously this hasn't happened yet, but I would still like it to. Which begs the question though, where it should live at this point:

• The logical place would be godoc, because we want it to serve code walks for user packages. But that would mean duplicating the code from the website-repo, where it's now homed (or factoring it out into a separate package, used by both).
• Another super useful and reasonable place would be pkg.go.dev. Which can't be contributed to by the community, so the implementation and maintenance would fall on the Go team then.
• Lastly, it could be a separate tool, in which case I guess this issue can be closed, because it may as well live outside the Go org.

The general trend seems to be toward splitting things out of godoc. I think the last option makes sense, and is at least a sensible starting point regardless of where it ends up.