-
Notifications
You must be signed in to change notification settings - Fork 46
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
Escape square brackets less #112
Comments
I don't think they add much, and they conflict with mdformat which escapes square brackets (executablebooks/mdformat#112). cc #231
I don't think they add much, and they conflict with mdformat which escapes square brackets (executablebooks/mdformat#112). cc #231
I'm starting to think it might be better to leave this as
|
If this is not left as a Escape all square brackets unless all of the following are true for a closed pair of brackets (
|
I'll put a plus one on fixing this. |
FWIW, |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I think this issue also impacts using The original content: [company branding]({{< ref "company-branding.md" >}} "Branding Configuration") And the formatted result \[company branding\]({{\< ref "company-branding.md" >}} "Branding Configuration") This will break the Hugo rendering; could you please let me know if there is a configuration parameter or plugin that will prevent this happening? |
This is also an issue with [`Object 1`][package.module.object1] even an option to disable the escaping would be a huge improvement for my use case (we don't usually use reference links, so the likelihood to break things is really low) |
I just noticed another problem with escaping brackets: Gitea uses |
Anybody running into this, have a look at mdformat-mkdocs with the |
@afuetterer Thenk you for sharing - it reminds of the alternative: have an option to control the behavior. And it got me back to this page. Personally I think that even a standalone Personally I am not into mdformat to have "everything" "fixed" (in some cases breaking it). There are also quite a few developers that do not want tools to make many "intrusive" changes. My original issue occurred when I had two spacea after the markdown tickbox |
Hi everyone! I'm pretty interested in fixing this. I don't know the mdformat codebase, but I'll be willing to take a stab at implementing this (even if slowly), if someone is willing to point me in the right direction and hold my hand a little.
|
Linked issue #110
Prettier seems to do a better job at square bracket escaping. Mdformat currently always escapes square brackets (to not accidentally produce link label enclosures) whereas it seems that Prettier keeps escapes from the source text.
The token stream we get from the parser is mainly just abstract syntax, so we don't know if the escapes were there in the source or not. Thus doing exactly what Prettier does is not currently easy to implement.
Like with other escapes, we could try to come up with logic that detects cases where link label enclosure certainly will not be accidentally produced and not escape if that is the case.
Note that this approach when implemented well enough can actually be an improvement over simply sustaining escapes from source, as it will automatically remove needless escapes.
The text was updated successfully, but these errors were encountered: