Slice without explicit html attributes about markdown HOT 9 CLOSED

Have you considered including the html attributes and stripping them before using them “elsewhere”? It may be a simpler task, all things considered.

This seemed like a good idea to me, so I've done some investigating -- the external tool that uses my markdown file is implemented in Ruby and uses Kramdown, which supports the same syntax for header ids as this library, so problem solved 😄 Thanks a lot for the quick responses and the good idea!

Considering that adding this feature to this package introduces a fair amount of complexity and has some non-trivial problems, while the use case for such a feature is not that common, I'm not sure it is worth the effort.

from markdown.

Glad to hear that your issue has been solved.

Although adding implicit anchor names is a nice idea, the implementation is non-trivial and would require further elaboration. For now, I am closing this issue. If there is future demand, the issue can be reopened.

from markdown.

It is possible to use the slice option without using the explicit html attributes?

No, this is currently not possible. The approach drafted in #28 suffers from problems related to character escaping. A possible (and easy-to-implement) solution would be to support slicing based on section numbers, although this would be quite a brittle approach. Would this be an option for you?

from markdown.

Would it perhaps be possible to create a default anchor, i.e. "My fancy markdown title" -> "my-fancy-markdown-title".

from markdown.

Yes, that would be quite possible and probably also a good idea, thank you for the suggestion. 🙂
I may not be able to work on this earlier than in (late) February, though.
If you would like to implement the feature yourself (and see your name in the release notes), I can assist with the implementation.

from markdown.

The default (implicit?) anchor is also not completely straightforward to implement.
A couple of obstacles that come to mind:

• Exotic unicode characters can be difficult to cast to ASCII and the user may not know what the default anchor is.
• Repeated headings would require some sort of numbering (i.e. “my-fancy-markdown-title-2”), which, again, makes it difficult for the user to know what the default anchor is.

from markdown.

I hadn't really thought about those case, but upon further reflection, I think it is probably best to do as little as possible automatically, i.e.

1. If the header cannot be converted due to weird unicode, referring to it would lead to an error. I haven't had a chance to look at the source code, but is it a requirement to have ascii anchors? If not, we could also use the same logic that is used when those unicode characters are encountered in the body of the markdown file, and allow that as anchors.
2. If two headers result in the same anchor and a user refers to it, it would error (or have the same behaviour as what happens now when you put the same anchor on two headings with html attributes).

If such an error is encountered, it would be up to the user to provide alternative anchors via the html attribute system that exists today. This way, there is minimal behaviour that would potentially surprise users.

As for how the user would know which header is what, perhaps an additional option can be provided, which would print the anchors with the headings, for example this code:

### Introduction
#### Who am I?

Would, with showAnchors=false, result in

Introduction

Who am I?

While showAnchors=true results in

Introduction (id: introduction)

Who am I? (id: who-am-i)

(Of course, this is all just me talking, I haven't looked at the implementation, so no idea if it is feasible or even sensible). I should have some time starting next week to look at potentially implementing this, but my experience with Latex packages is limited, so it will probably take a while.

Slicing based on section numbers (or even based on line numbers) would also work in my case, but is indeed a bit fragile.

from markdown.

1. If the header cannot be converted due to weird unicode, referring to it would lead to an error. I haven't had a chance to look at the source code, but is it a requirement to have ascii anchors? If not, we could also use the same logic that is used when those unicode characters are encountered in the body of the markdown file, and allow that as anchors.

It is not unsolvable, but we would need to disable the default LaTeX behavior in pdfTeX, which is to expand non-ASCII (more specifically, non-8bit) characters into TeX macros, so that Lua does not receive a garbled anchor name. I would have to look into the ConTeXt side of things to see what the situation is there. It can be done, but it would increase code complexity.

Equally importantly, spaces are considered to be separators in the value of slice, i.e. at least spaces would have to be replaced with a dash or another character.

2. If two headers result in the same anchor and a user refers to it, it would error (or have the same behaviour as what happens now when you put the same anchor on two headings with html attributes).

Currently, such behavior is undefined. I have not tested this corner case, but if I recall the implementation correctly, two sections with the same id will lead to both getting included. This can be a useful behavior that produces slices with “holes”, but it may change in the future and it also produces invalid HTML.

As for how the user would know which header is what, perhaps an additional option can be provided, which would print the anchors with the headings, for example this code: […]

Note that there is a posibility that the Markdown package will make use of other HTML attributes in the future. Therefore, it may be better to have a showHeaderAttributes option, which is consistent with the current naming, and would dump all the attributes of a header.

(Of course, this is all just me talking, I haven't looked at the implementation, so no idea if it is feasible or even sensible). I should have some time starting next week to look at potentially implementing this, but my experience with Latex packages is limited, so it will probably take a while.

A lot of this is feasible, see above. Best of luck with your efforts. I will be here if you need to discuss anything related to the implementation or design.

Slicing based on section numbers (or even based on line numbers) would also work in my case, but is indeed a bit fragile.

We could produce several implicit header names, including section numbers:

# My first heading
<!-- implicitly #section-1 -->
<!-- implicitly #my-first-heading -->
<!-- implicitly #my-first-heading-1 -->

## My second heading   {#bar}
<!-- not implicitly #section-1.1, since the user overrides #section-1.1 below -->
<!-- implicitly #my-second-heading -->
<!-- implicitly #my-second-heading-1 -->

## My second heading   {#section-1.1}
<!-- implicitly #section-1.2 -->
<!-- implicitly #my-second-heading -->
<!-- implicitly #my-second-heading-2 -->

There is still a potential for clashes (i.e. ## Section 1.1 would produce a conflicting implicit header name as would ## My second heading 2), so perhaps this requires some more careful thought before we jump to implementation. I would be glad to hear your thoughts on this.

Perhaps it would also be useful to look at other implementations (Pandoc), which already implement implicit anchor names, so that we don't reimplement the wheel and do remain compatible (while also adding our own useful extensions such as the section names).

from markdown.

I can't make changes to the markdown file, since it is also used elsewhere, where the special syntax for html attributes is not supported.

Have you considered including the HTML attributes and stripping them before using them “elsewhere”? It may be a simpler task, all things considered.

from markdown.