Generate wrong index for go 1.18 generic code about gomarkdoc HOT 6 CLOSED

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?

from gomarkdoc.

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>)

from gomarkdoc.

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.

from gomarkdoc.

@princjef any update on this?

from gomarkdoc.

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/.

from gomarkdoc.

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

from gomarkdoc.