Refactoring: split into files

[Einenlum]

Hi there.

First, thank you for your great work ❤️

Following this discussion #382 , I wanted to try to make the extra part more flexible.
I realized it's quite hard to follow the code because everything is packed in a huge file.

This PR is a first step to refactor the code and to then make the extras more flexible/pluggable.

Wolud you agree to split this code? I don't mind about the name of the files if you don't like this organization. But I think it would be nice to avoid having just one big pile of code.

[nicholasserra]

@Crozzers Youve been in this codebase more than I have recently. Curious if you have any opinions on this refactor and the linked issue?

[Crozzers]

I think in terms of code readability and ease of maintenance, this is the right move. Splitting the library up will also make it easier for custom extras and such. However, splitting the library into multiple files will reduce it's portability a fair bit, which is one of the library's selling points. Overall I don't really mind either way but out of curiosity, what is the blank parser_objects.py file for?

[Crozzers]

Oh and in terms of the linked issue, I think custom extras would be a great feature to have but it might get complicated for the end user when configuring when their custom extra is triggered. They might, for example, want to process custom link syntax before _do_links is triggered, or they might wish to post-process them.

[Einenlum]

out of curiosity, what is the blank parser_objects.py file for?

Woops, that was a mistake. I just pushed force the git history to remove that blank file. Thank you! :)

Oh and in terms of the linked issue, I think custom extras would be a great feature to have but it might get complicated for the end user when configuring when their custom extra is triggered. They might, for example, want to process custom link syntax before _do_links is triggered, or they might wish to post-process them.

Seems like Python Markdown uses Preprocessors and Postprocessors. Maybe it's the way?

[nicholasserra]

We have pre and post hooks. My worry is that there's simply no way to really refactor-out the extras stuff from the core library without rewriting the whole thing.

Maybe keep exploring your ideas @Einenlum assuming this was merged and see where you land. I think this is probably fine to land either way but i'm kind of curious to see what's even possible after this for the extras stuff.

[Tobi-De]

Hey @Einenlum, hope you are doing well.
I was trying to add a new extension to the package to display mermaid diagrams and realized that the code was too complicated to extend and found this pull request. Since there is no recent activity on this, I was wondering how things were going. I am available to help if needed.

[Einenlum]

Hey @Tobi-De,
Sorry for the very late reply. Honestly I ended up using https://python-markdown.github.io/ and its extensions, which did what I expected.

I don't have any incentive to work on this now, but I wish good luck to anyone who wants to dive into it and refactor things :)

[Tobi-De]

Hey @Tobi-De, Sorry for the very late reply. Honestly I ended up using https://python-markdown.github.io/ and its extensions, which did what I expected.

I don't have any incentive to work on this now, but I wish good luck to anyone who wants to dive into it and refactor things :)

I understand, that's fair.
Personally, I found mistune very interesting, I haven't tried it yet but I will probably use it for what I am working on.