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.

Sign up for GitHub

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

Jump to bottom

[Markdown] does not recognize links without dots #1930

Closed
evandrocoan opened this issue Mar 30, 2019 · 7 comments · Fixed by #3167
Closed

[Markdown] does not recognize links without dots #1930

evandrocoan opened this issue Mar 30, 2019 · 7 comments · Fixed by #3167
Labels
T: enhancement Improvement of existing language features

Comments

@evandrocoan
Copy link
Contributor

image

http://server/user
https://github.com/

Github Markdown does:
http://server/user
https://github.com/
@keith-hall
Copy link
Collaborator

keith-hall commented Mar 31, 2019 •
edited
Loading

according to the GFM docs:

An extended url autolink will be recognised when one of the schemes http://, https://, or ftp://, followed by a valid domain, an a valid domain must contain at least one period.

So it may be a bug in the implementation that GitHub linkifies http://server/user, or it may be a bug in the spec...

@evandrocoan
Copy link
Contributor Author

Links without dot are accepted as valid for intranets while working inside an organization. Maybe for Internet they must have a dot because of how it was designed, but while working inside companies you can have links without a dot.

@keith-hall
Copy link
Collaborator

I realize the links are valid, I'm just opening a discussion about whether to follow the spec to the letter or deviate from it for "observed compatibility"/"common use", the implication being that other apps that work with/parse GFM may behave differently.
I personally also use intranet links in my Markdown documents, so I would be tempted to "fix" this issue, I just wanted more feedback first. :)
I wonder if anyone has filed an issue against the GFM spec regarding this.

@evandrocoan
Copy link
Contributor Author

I do not think anyone has filled this issue. Is this their issue tracker? https://github.com/commonmark/CommonMark

The answer should be simple, does the spec for GFM is representing links for internet only or internet and intranets? If it is for both, then, GFM is bugged. If it is for internet only, then, is not a bug, therefore, an enhancement for GFM would be for it to also accept links for intranets too.

@keith-hall
Copy link
Collaborator

github/cmark-gfm#93
github/cmark-gfm#98

evandrocoan added a commit to evandroforks/SublimePackageMarkdown that referenced this issue Mar 31, 2019
@evandrocoan
Fixed Markdown does not recognize links without dots
ce8c457 
sublimehq/Packages#1930
@michaelblyons
Copy link
Collaborator

Note that you can always force link-highlighting with <>:

<http://server/user>
<https://github.com/>

@deathaxe
Copy link
Collaborator

Bitbucket, Github, Gitlab, Python Markdown, MultiMarkdown all translate those links without dots, regardless what specs say.

MultiMarkdown requires another / to do so, but that's a detail, IMHO.

So from practical point of view, highlighting autolinks without dots would be fine.

@deathaxe deathaxe added the T: enhancement Improvement of existing language features label Aug 19, 2021
deathaxe added a commit to SublimeText-Markdown/MarkdownEditing that referenced this issue Sep 18, 2021
@deathaxe
Syntax: Refactor autolink contexts
8d36e15 
This commit is a major overhaul of autolink contexts

It addresses:
- sublimehq/Packages#1930
- sublimehq/Packages#2542
deathaxe added a commit to deathaxe/sublime-packages that referenced this issue Dec 11, 2021
@deathaxe
[Markdown] Sync with MarkdownEditing 3.1.0
ebf80a8 
Fixes sublimehq#1930
Fixes sublimehq#2542
Fixes sublimehq#2857
Fixes sublimehq#3073
Fixes sublimehq#3154
Fixes sublimehq#3157

This commit proposes to apply refactored Markdown syntax from
MarkdownEditing, which was originally been based on ST's default
Markdown syntax.

It is mainly a reorganization of existing contexts/patterns, which
include several fixes which have been applied during refactoring.

It does not yet introduce branching to a broader extend in order to
limit changes to the syntax test file. Those are planned for future
PRs after being developed and tested in MarkdownEditing repo.

Note:

1. All 3rd-party syntaxes or extensions have been removed.
2. For details about single changes, please follow MarkdownEditing's
   commit history. All syntax related commits start with "Syntax: ".
@deathaxe deathaxe mentioned this issue Dec 11, 2021
Merged
deathaxe added a commit to deathaxe/sublime-packages that referenced this issue Dec 11, 2021
@deathaxe
[Markdown] Sync with MarkdownEditing 3.1.0
e2f597f 
Fixes sublimehq#1930
Fixes sublimehq#2542
Fixes sublimehq#2857
Fixes sublimehq#3073
Fixes sublimehq#3154
Fixes sublimehq#3157

This commit proposes to apply refactored Markdown syntax from
MarkdownEditing, which was originally been based on ST's default
Markdown syntax.

It is mainly a reorganization of existing contexts/patterns, which
include several fixes which have been applied during refactoring.

It does not yet introduce branching to a broader extend in order to
limit changes to the syntax test file. Those are planned for future
PRs after being developed and tested in MarkdownEditing repo.

Note:

1. All 3rd-party syntaxes or extensions have been removed.
2. For details about single changes, please follow MarkdownEditing's
   commit history. All syntax related commits start with "Syntax: ".
deathaxe added a commit that referenced this issue May 7, 2022
@deathaxe
[Markdown] Refactor Syntax (#3167)
b31d078 
[Markdown] Refactor Syntax

Fixes #1930
Fixes #2542
Fixes #2857
Fixes #2942
Fixes #3073
Addresses #3154 (in ST3 compatible way)
Fixes #3157
Fixes #3170
Addresses #3228

This commit refactors Markdown syntax to 

1. improve compliance with CommonMark specification:
   https://spec.commonmark.org/0.30

   Many tests are added to proof compliance:
   https://spec.commonmark.org/0.30/spec.json

   Latest GFM syntax is based on CommonMark at the time writing,
   so those rules are included as well:
   https://github.github.com/gfm/

2. convert most anonymous to named contexts for better support
   of inheritance.

3. reorganize syntax into logical sections for better readability
   and maintainability.

4. address most Markdown related issues of sublimehq/Packages repo.
   
Main changes are:

- fix CommonMark compatibility of backslash escapes
- fix CommonMark compatibility of block quotes
- fix CommonMark compatibility of html entities
- fix CommonMark compatibility of fenced code blocks
- fix CommonMark compatibility of indented code blocks
  (mixed tabs/spaces)
- fix CommonMark compatibility of reference definitions
- fix CommonMark compatibility of thematic breaks
- update strike-through markup to use 2 tildes only
- reorganizing contexts in logical sections

Benchmarks:

This commit has no impact on parsing performance.

Notes: 

1. Some remaining CommonMark incompatibilities need further work
   using ST4's "branching" feature.
2. Main refactoring work was done in MarkdownEditing package and
   released with version 3.1.1. This commit contains the result
   of that work, except some features which rely on 3rd-party
   (syntax) packages.

   Removed features are:
   - coffee script support in front-matter
   - numerous code-block syntaxes (E.g.: Ada, Coffee Script, ...)
   - LaTex blocks
   - custom `<kbd>` tag highlighting as it doesn't meet 
     quality expectations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
T: enhancement Improvement of existing language features
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[Markdown] Sync with MarkdownEditing 3.1.1 deathaxe/sublime-packages
4 participants
@michaelblyons @evandrocoan @keith-hall @deathaxe