Generate wrong index for go 1.18 generic code

[chen3feng]

eg:

type DList [func NewDListT any *DList[T]](<#func-newdlist>)

See the following link for more examples:

https://github.com/chen3feng/contalgo/blob/decca4ca119775b6bed62a1ef5b35e76696f17f3/README.md#index

Thanks.

[MarvinJWendt]

Screenshot:

Generated markdown:

- [type Stack](<#type-stack>)
  - [func New[T any]() Stack[T]](<#func-new>)            <-- wrong output
  - [func (s *Stack[T]) Clear()](<#func-stackt-clear>)
  - [func (s *Stack[T]) Contains(item T) bool](<#func-stackt-contains>)

[thediveo]

There is probably more wrong markdown generated here than just the line you point out. Looking at the other links generated, they rather tend to work by accident, because [...] is not immediately followed by (...). I'm afraid the whole markdown thing is falling apart in light of Go generics, as there is no common markdown way to escape square/rounded brackets in order to not totally confuse markdown interpreters in case of Go generics signatures.

[MarvinJWendt]

It's possible to have that kind of links looking fine if you put them into a code block:

• func New[T any]() Stack[T]

- [`func New[T any]() Stack[T]`](https://example.com)

That would change the look slightly, but it works.

EDIT: I just found a way to escape the links:

• func New[T any]() Stack[T]

- [func New[T any]\() Stack[T]](https://example.com)

So the solution is to put a backslash between [] and (). @princjef do you have any ETA on this?

[MarvinJWendt]

@princjef any update on this?

[egonelbre]

One fix would be to replace []() with their html code counterpart:

r := strings.NewReplacer(
	"[", "[",
	"]", "]",
	"(", "(",
	")", ")",
)

https://go.dev/play/p/MMr04QkvnTW -- although, that would be really annoying when reading in an editor.

But, yeah, the strings.ReplaceAll(s, "](", "]\(") seems like a nicer output.

Also, there's an option to replace them with some similar unicode-symbol, e.g. https://symbl.cc/en/27E6/.

[princjef]

Gomarkdoc does some general escaping with \ which generally solves this problem, I think it's just being skipped here (accidental omission). Let me see if applying that escaping is enough without messing up the rendering. Raw readability of the code will suffer, but up until now I've favored proper rendering over maximum readability of the raw code