NumPy 2.0.0 Release Notes
NumPy 2.0.0 is the first major release since 2006. It is the result of
11 months of development since the last feature release and is the work
of 212 contributors spread o...
I’m curious about this. The source text of your comment appears that your comment was just the URL with no markdown. For your comment about a markdown parsing bug to be true, shouldn’t the URL have been written in markdown with []() notation (or a space between the URL and the period) since a period is a valid URL character? For example, instead of typing https://google.github.io/styleguide/cppguide.html., should [https://google.github.io/styleguide/cppguide.html.](https://google.github.io/styleguide/cppguide.html) have been typed?
Edit to be clear: This means that both of our markdown parsers are wrong relative to the commonmark spec. But I’ll argue that if a parser is going to attempt to autolink this, then handling trailing punctuation is better than not.
I did not know about autolinks - thanks for the link!
It is interesting how different parsers handle this exact situation. I usually am cautious about it because I typically am not sure how it will be handled if I am not explicit with the URL and additional text.
Do you think a style guide is enough for an open source code base? Contributions could be coming from lots of directions, and the code review process to enforce a style guide is going to be a lot of work. Even rejecting something takes time.
Yup, we do it for Python and Javascript at work, and I do it on my Rust projects (and my older C projects). I don’t see why C++ should be any more difficult.
With a good style/best-practice guide, C++ can be quite productive of a language to work with.
Those kinds of guides typically define which standard/convention to use and which features not to use (cough exceptions cough).
I highly recommend Google’s C++ style guide: https://google.github.io/styleguide/cppguide.html.
You accidentally added a dot at the end of the link. Here’s the fixed one https://google.github.io/styleguide/cppguide.html
I intentionally added a period because it was the end of a sentence.
If your Lemmy app messed it up, then that’s a bug in its markdown parser.
I’m curious about this. The source text of your comment appears that your comment was just the URL with no markdown. For your comment about a markdown parsing bug to be true, shouldn’t the URL have been written in markdown with
[]()notation (or a space between the URL and the period) since a period is a valid URL character? For example, instead of typinghttps://google.github.io/styleguide/cppguide.html., should[https://google.github.io/styleguide/cppguide.html.](https://google.github.io/styleguide/cppguide.html)have been typed?Huh. This got me curious.
Yes, I did just type a bare URL. Every mature markdown parser I’ve used turns this into a link, and appropriately handles trailing punctuation.
So I went to the spec, and it’s explicitly called out that this is not an autolink. Autolinks must be explicitly surrounded with angle brackets
<>.So yeah \shrug.
https://spec.commonmark.org/0.31.2/#autolinks
Edit to be clear: This means that both of our markdown parsers are wrong relative to the commonmark spec. But I’ll argue that if a parser is going to attempt to autolink this, then handling trailing punctuation is better than not.
I did not know about autolinks - thanks for the link!
It is interesting how different parsers handle this exact situation. I usually am cautious about it because I typically am not sure how it will be handled if I am not explicit with the URL and additional text.
Do you think a style guide is enough for an open source code base? Contributions could be coming from lots of directions, and the code review process to enforce a style guide is going to be a lot of work. Even rejecting something takes time.
This kind of thing can be easily automated nowadays. It’s not really a problem.
Yup, we do it for Python and Javascript at work, and I do it on my Rust projects (and my older C projects). I don’t see why C++ should be any more difficult.