Support for anchors

[bgamari]

It would be nice if the document AST would have some way of representing anchor points. This would enable features like #1117 and hyperlinked section, table, and figure references (proposed in #813).

[bgamari]

As it turns out this is currently being discussed in https://groups.google.com/forum/#!topic/pandoc-discuss/zlSp_u3oEO0.

There is the question of whether anchors should be block or inline elements. While conceptually block seems like the more obvious choice, for supporting #1117 inline is slightly more convenient as citeproc-pandoc currently only produces Inlines.

[bgamari]

This issue is demonstrated in https://github.com/bgamari/pandoc-citeproc/compare/anchors

[mpickering]

I had an email exchange with John about this a while back. (Checking back now.. it was 5am before a flight when it happened). I think the conclusion was for time being it was better to use empty span elements (with an identifier) rather than introducing a new element to the AST. What are your thoughts?

[bgamari]

This sounds like a reasonable approach. That being said, would this not be rather HTML/markdown-specific? How would this be handled for documents that targeted, e.g., latex?

[mpickering]

I think they get translated to hyperref targets.

[marijnh]

What does an empty span element with an identifier look like? Using two backticks followed by {#identifier} doesn't parse. Or are you talking about an html <span>?

After moving from AsciiDoc to Pandoc, almost everything is great, but the inability to succinctly insert anchors at any position (I'm currently writing <a name="foo"></a> a lot) does really cause problems. It's verbose, and since Pandoc doesn't know these are identifiers, I can't link them just by saying [foo], for example.

[jgm]

Use <span id="foo"></span>, and it will be parsed into a
native pandoc Span element. So far there is no non-HTML
syntax for this. It would be better, I agree, if there
were, and there are various alternatives. One that I like,
and am considering for CommonMark, is overloading empty
reference link definitions:

[foo]:

Some text here.

See [the text above][foo].

+++ Marijn Haverbeke [Sep 08 15 05:16 ]:

What does an empty span element with an identifier look like? Using two
backticks followed by {#identifier} doesn't parse. Or are you talking
about an html ?

After moving from AsciiDoc to Pandoc, almost everything is great, but
the inability to succinctly insert anchors at any position (I'm
currently writing a lot) does really cause problems.
It's verbose, and since Pandoc doesn't know these are identifiers, I
can't link them just by saying [foo], for example.

—
Reply to this email directly or [1]view it on GitHub.

References

1. Support for anchors #1299 (comment)

[neopaf]

we also want this

[mb21]

You can already reference all elements that have attributes (by giving them an id) and there's a discussion to add attributes to all elements.

Meanwhile, pandoc's markdown got its native span syntax, for an empty one:

[]{#myid}

[Pzixel]

@mb21 could you be in more details pls? I'm trying to convert markdown to rst, and anchors should be translated into :ref: attributes. This is my test page (with syntax you proposed):

- [feeAmountTickSpacing(uint24 fee)][]{#IUniswapV3Factory-feeAmountTickSpacing-uint24-}

# Function `feeAmountTickSpacing(uint24 fee) → int24` {#IUniswapV3Factory-feeAmountTickSpacing-uint24-}

A fee amount can never be removed, so this value should be hard coded or cached in the calling context

But it gets rendered into

-  [feeAmountTickSpacing(uint24
   fee)][]{#IUniswapV3Factory-feeAmountTickSpacing-uint24-}
.. _IUniswapV3Factory-feeAmountTickSpacing-uint24-:

Function ``feeAmountTickSpacing(uint24 fee) → int24``
=====================================================

A fee amount can never be removed, so this value should be hard coded or
cached in the calling context

Which is invalid syntax.

[tarleb]

@Pzixel if you found a bug, please open a new issue. Questions are best send to the pandoc-discuss mailing list. Commenting on old issues is generally frowned upon, as it will notify everybody who participated in this issue.

[Pzixel]

Oh sorry, I though it's related. I'm not sure if it's a bug or just not supported.
I'l file another issue ,thanks!