Earmark - Elixir's Markdown Converter

Your Libraries & OS Mentoring Libraries
,
66

yeah I was not suggesting to use IALs at all we are on the same wavelength, still I never had a request for this, IIRC

67

I don’t think a domain option would be necessary because even that has limitations, like, do you match sub domains or not? Then maybe you will have to support wildcards, dot prefixes, etc.

So I would say a function that receives the url and returns a list of attributes would likely be enough. The default is to return an empty list - the current behavior - and then people can customize it to consider the domain, sub domains, etc.

But regarding your main request, I don’t have a need for it right now. :slight_smile:

2 Likes
68

I am making a notes app, and most of the links typed in the note by users are external links.

The domain way looks good to me. It gives a decent enough context to start with.

BTW thanks for the awesome work you are doing.

70

That seems the most flexible and also the easiest way to go :slight_smile:
Thank you all for your inputs

71

as reference Allow customisation of links with a function that returns attributes as a function of its URL · Issue #407 · pragdave/earmark · GitHub

And although not as convenient as the implementation you can already do this with the postprocessor option

 defp _add_target(ast_node)                                                                                                                                                                          
  defp _add_target({"a", _atts, _content, _meta}=node), do: merge_atts_in_node(node, target: "_blank")                                                                                                
  defp _add_target(anything), do: anything                                                                                                                                                            
                                                                                                                                                                                                      
  describe "Link reference definitions" do                                                                                                                                                            
    test "postprocessor can already do it" do                                                                                                                                                         
      markdown = "[foo]: /url \"title\"\n\n[foo]\n"                                                                                                                                                   
      html     = "<p>\n<a href=\"/url\" target=\"_blank\" title=\"title\">foo</a></p>\n"                                                                                                              
      messages = []                                                                                                                                                                                                                                                                                                                                  
      assert as_html(markdown, postprocessor: &_add_target/1) == {:ok, html, messages}                                                                                                                
    end

leaving merge_atts_in_node as an exercise for the reader :wink:

2 Likes
72

So here is my implementation, any suggestions before I release?

73

Are there plans to implement some sort of html sanitizing for the output?

74

No, Dave’s and YHS’s point of view has always been that this is beyond the scope of Earmark.

Furthermore now that we have EarmarkParser someone can write a sanitizing renderer easily.
I mean sanitizing is not easy but the renderer would be.

IIRC the usual converters as seen on Babelmark e.g. do not do this either, but I may be wrong

75

Prereleases of 1.4.16 for Earmark and EarmarkParser

As 1.4.16 provides some new features which ease the integration of Earmark into other programs especially in combination with EarmarkParser’s new and experimental Annotations feature I would like to annonce the Release of two -pre versions, in the hope to get some feedback for the new features.

EarmarkParser 1.4.16-pre

Earmark 1.4.16-pre2

3 Likes
76

I just released

EarmarkParser 1.4.16

1.4.16 2021/10/07

and

Earmark v1.4.16

1.4.16 2021-10-07

2 Likes
77

I just released Earmark v1.4.17, here are the release notes

this relase concerns rendering only there is no parser feature or bug fix and therefore it still depends on EarmarkParser 1.4.16

N.B Expect a non negative increasing delta between Earmark and EarmarkParser patch versions

Earmark 1.4.17 2021-10-27

5 Likes
78

Earmark Parser 1.4.17 released

1.4.17 2021-10-29

1 Like
79

Earmark 1.4.18 released

here are the Release Notes:

1.4.18 2021-10-30

2 Likes
80

EarmarkParser 1.4.18 released

1.4.18 2021-12-04

81

Here is the compagnon release for Earmark

Earmark 1.4.19 2021-12-04

This release is updating to EarmarkParser v1.4.18 with these RELEASE NOTES

82

Is there any way to convert an Earmark AST back to markdown? There could be usage cases such as:

  • parse an markdown file, do some transformation, and then convert back to markdown
  • take a html file, parsed with floki, convert the AST into earmark AST (they looks close enough) and then write out a markdown file
1 Like
83

There’s code that sounds close to what you’ve described in Livebook:

84

Thanks. @RobertDober , May I suggest you to take the above mentioned code and merge it into Earmark itself? It is small, useful and more closely related to Earmark than Livebook. Also, you guys obviously already work closely together.

85

While the first use case is likely a good idea, I am not sure how useful this case would be in practice:

Markdown is a simple output format, so it may be easier to go from HTML → Markdown, without going through Earmark AST. For example, even if this feature is added to Earmark, we would likely keep our conversion as is instead of introducing an intermediate step. Especially because we only modify the structure of the Markdown document, never the contents of the paragraphs.

86

@derek-zhou
I too fail to see why you would like to manipulate the Earmark AST instead of the Floki AST? I guess reuse of already existing transformation functions might be an argument.
In that case it might perhaps be a good idea to generalize them to work on Floki’s AST instead?