Skip to content
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

[Markdown] Ligatures that start with < aren't rendering #1453

Closed
appsforartists opened this issue Mar 8, 2018 · 7 comments · Fixed by #2151
Closed

[Markdown] Ligatures that start with < aren't rendering #1453

appsforartists opened this issue Mar 8, 2018 · 7 comments · Fixed by #2151

Comments

@appsforartists
Copy link

Ligatures that begin with < are rendering as two characters in Markdown. They will draw correctly if placed immediately after a backtick or in in a syntax like TypeScript.

screen shot 2018-03-08 at 12 37 02 am

@appsforartists
Copy link
Author

I'm using Inconsolata, but I can reproduce with Fira Code too.

@keith-hall
Copy link
Collaborator

I guess this is due to

bracket:
- match: '<(?![a-z/?\$!])'
comment: |
Markdown will convert this for us. We match it so that the
HTML grammar will not mark it up as invalid.
scope: meta.other.valid-bracket.markdown
. It could be solved by removing the meta scope, but I think it is useful to have the scope there.

@appsforartists
Copy link
Author

I bet there's an exclusion character in whatever flavor of regex sublime uses. You could presumably whitelist <= and <- without affecting HTML parsing.

@FichteFoll
Copy link
Collaborator

An option would be to match these two specifically before this match to ensure they end up in the same token.

@keith-hall iirc tokenization happens regardless of whether a scope is assigned or not, so removing the meta scope wouldn't help.

@deathaxe
Copy link
Collaborator

Looks fixed in ST 3207

deathaxe pushed a commit to deathaxe/sublime-packages that referenced this issue Aug 25, 2019
This PR proposes to close some already fixed issues, which were not (correctly) referenced in the fixing pull requests.

Closes sublimehq#442
Closes sublimehq#685
Closes sublimehq#691 (invalid)
Closes sublimehq#795
Closes sublimehq#807
Closes sublimehq#903
Closes sublimehq#1141
Closes sublimehq#1172
Closes sublimehq#1245
Closes sublimehq#1257
Closes sublimehq#1286
Closes sublimehq#1320
Closes sublimehq#1357
Closes sublimehq#1382 (wontfix)
Closes sublimehq#1403
Closes sublimehq#1451
Closes sublimehq#1453 (maybe)
Closes sublimehq#1472
Closes sublimehq#1495
Closes sublimehq#1540
Closes sublimehq#1542
Closes sublimehq#1565
Closes sublimehq#1576
Closes sublimehq#1625
Closes sublimehq#1880
Closes sublimehq#1898
Closes sublimehq#1940 (invalid)
@wbond
Copy link
Member

wbond commented Oct 24, 2019

@appsforartists Are you still seeing this with the latest version of Sublime Text 3?

@appsforartists
Copy link
Author

I can reproduce the original issue in 3211.

deathaxe pushed a commit to deathaxe/sublime-packages that referenced this issue Oct 25, 2019
wbond pushed a commit that referenced this issue Oct 29, 2019
mitranim pushed a commit to mitranim/Packages that referenced this issue Mar 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants