Suggestion: allow doc to include easy links to API types, not just packages

[bobhy]

Description

When writing doc about table styling in the Collections section, I found myself wanting to
refer to specific widget.Table methods and fields and to link to the current (V2.6) API for Table.
E.g I wanted to refer to Table.SetColumnWidth() and have it link to relevant API documentation.

I found pretty quickly that the API doc pages for widget.Table do not have anchors for public methods or fields, and I guess that's the norm in golang, so I was willing to settle for a link to the Table type API page itself, and to use something like [Table.SetColumnWidth()](/api/widget/table) in my section doc.

But the link has to be /api/v2.6/widget/table, and that means someone will have to update all those links whenever a new release comes out. It seems too much maintenance overhead.

I note that this is the general style of the non-API sections of the fyne doc, like Getting Started, Tour, ... Pages in those sections refer to public elements of types, but generally do not link to them.

I think the docs could be made much more usable and dev-friendly if it were easy to link from the other sections to the current API section for a type (and even to public members of the type).

Proposed solution

Check the generated .md files (direct from godocdown) in at an unversioned repo path:

/api/**/*.md

Rather than the current

/api/V2.6/**/*.md

Then in all the other sections of the doc, a link like:

[`widget.Table`](/api/widget/Table)

would just work.

I don't see the advantage of checking these files into a versioned path, perhaps it's a historical artifact from a previous layout of the doc site?

Alternatives to proposed solution

1. Add a redirect_from to each page of generated API doc, specifically for the pages representing a type within a package.

e.g, for widget.table, in the (currently generated) stub file /api/<current>/widget/table.md
include a redirect_from in the generated front matter:

---
redirect_from: /api/widget/table
---

Currently, genapi.sh does generate redirect stub files for each package, but godocdown does not do this for the types within the package.

But why maintain all those stub files in the first place?

[andydotxyz]

I love this idea - but I don't think it needs the restructuring you describe. If I am in the widget package then [widget.Table](table) should work. If the code was in the container (or other) package then [widget.Table](../widget/table) for example. Just using relative paths.

We could totally add the missing anchors for methods & fields though. Godocdown used is just a fork I have which is pretty easy to modify.

I don't see the advantage of checking these files into a versioned path, perhaps it's a historical artifact from a previous layout of the doc site?

The idea was for historical reasons yes. Maybe now that we have "since" headers it is less required.