-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The four extensions in one package "extras" #18
Conversation
According to the result of the discussion in my feature request, the packages are merged into one named "extras". The method names are adapted accordingly. And I created an additional package called "ast" containing higher level methods for the parser tree.
The example from the README contains this:
The subscripts are failing. This works:
This does not:
The Hugo integration bit is here: You'll need to change the replacement path in go.mod. That will, of course, go away once this is merged. |
Yes, @bep, the only difference between Superscript and Subscript are the markers (a single '^' or '~'). All the other variables, functions, or methods only have different names. This redundancy could surly be removed. The insert doesn’t need to watch out for whitespace and has the same logic as strong emphasis. But first I need to address the problem @jmooring mentioned. My unit tests did not cover the cases |
The look-ahead for whitespace characters in super- in subscripts was meant for an edge case. LaTeX-like notation `x^2 + x^3` leads to a senseless formatting `x<sup>2 + x</sup>3`. But the look-ahead had the side effect to fail perfectly normal Markdown like `H~2~O text`.
The look-ahead for whitespace characters in super- and subscripts is essential because a caret or a tilde may also be used for other markup or literally. The enabled extensions shouldn’t force a user to escape all existing literal characters or interfere with other markup. Edge cases may remain.
…new approach with less code duplication.
This is a preliminary version. The goal is to create one NodeKind "inlineTag" for all simple inline tags. But I am not sure if it’s going to work out, so I want to leave this on record.
Sorry for the delay, I had to attend to a lot of changes in my life in the last weeks. Coming month my new full-time Job is going to start. I want to finish the extras package with the requested changes in the next days. |
There are new unit tests for the problem @jmooring found, and it's gone. The redundancy in the extensions is also gone. Only the necessary general structures for an inline tag remain which can be used for different tags. I have added a new mark tag because it was so easy: ==marked== -> The configuration follows now the same concept as I also changed I noticed that I am not as proficient with the Go workflow as I would like. I had to change the module path to my personal repo to integrate. |
To simplify integration testing I am merging this without tagging a release. The repository is still described as "Work in progress". |
Closes #12