[GH-ISSUE #150] New rule proposal: force emphasis style #1978

Closed
opened 2026-03-07 20:03:20 +03:00 by kerem · 13 comments
Owner

Originally created by @byzyk on GitHub (Oct 15, 2018).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/150

Emphasis (bold text copy) can be written in two ways: __bold text__ or **bold text**.

It would be good to force certain emphasis style to keep it consistent.

Please let me know if this could be merged in core repo so I can work on the implementation.

Originally created by @byzyk on GitHub (Oct 15, 2018). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/150 Emphasis (bold text copy) can be written in two ways: `__bold text__` or `**bold text**`. It would be good to force certain emphasis style to keep it consistent. Please let me know if this could be merged in core repo so I can work on the implementation.
kerem 2026-03-07 20:03:20 +03:00
Author
Owner

@DavidAnson commented on GitHub (Oct 15, 2018):

This makes sense, thanks. I assume there would also be an option for “consistent“. I’m asking that new rules start externally- more here: https://github.com/DavidAnson/markdownlint/blob/master/CONTRIBUTING.md

<!-- gh-comment-id:429919459 --> @DavidAnson commented on GitHub (Oct 15, 2018): This makes sense, thanks. I assume there would also be an option for “consistent“. I’m asking that new rules start externally- more here: https://github.com/DavidAnson/markdownlint/blob/master/CONTRIBUTING.md
Author
Owner

@byzyk commented on GitHub (Oct 15, 2018):

@DavidAnson cool, glad to hear that.

I'm going to implement this in our webpack docs first and give you an update on how it went. Gonna keep you posted.

<!-- gh-comment-id:429959573 --> @byzyk commented on GitHub (Oct 15, 2018): @DavidAnson cool, glad to hear that. I'm going to implement this in our webpack docs first and give you an update on how it went. Gonna keep you posted.
Author
Owner

@DavidAnson commented on GitHub (Oct 15, 2018):

Good luck. If you have any questions, let me know and I’ll try to help!

<!-- gh-comment-id:429963153 --> @DavidAnson commented on GitHub (Oct 15, 2018): Good luck. If you have any questions, let me know and I’ll try to help!
Author
Owner

@DavidAnson commented on GitHub (Oct 15, 2018):

Please let me know if the lack of internal helper methods is too annoying: https://github.com/DavidAnson/markdownlint/issues/134

<!-- gh-comment-id:429969143 --> @DavidAnson commented on GitHub (Oct 15, 2018): Please let me know if the lack of internal helper methods is too annoying: https://github.com/DavidAnson/markdownlint/issues/134
Author
Owner

@byzyk commented on GitHub (Oct 29, 2018):

Hey @DavidAnson!

I've come up with a custom rule for emphasis style. It worked pretty well for our case (see CI build failed).

Do you think this is something that can be merged to core repo? Feel free to dig into source code if you want to to check implementation.

I'd be happy to submit a PR shortly with test cases should you decide to give a green light on this one 🙂

<!-- gh-comment-id:433865029 --> @byzyk commented on GitHub (Oct 29, 2018): Hey @DavidAnson! I've come up with a custom rule for emphasis style. It worked pretty well for our case (see [CI build failed](https://travis-ci.org/webpack/webpack.js.org/builds/447713580)). Do you think this is something that can be merged to core repo? Feel free to dig into [source code](https://github.com/byzyk/markdownlint-rule-emphasis-style/blob/master/rule.js) if you want to to check implementation. I'd be happy to submit a PR shortly with test cases should you decide to give a green light on this one 🙂
Author
Owner

@DavidAnson commented on GitHub (Oct 29, 2018):

Great! I’ll be working on markdownlint again soon and will look into this (and shared.js) then.

<!-- gh-comment-id:433982565 --> @DavidAnson commented on GitHub (Oct 29, 2018): Great! I’ll be working on markdownlint again soon and will look into this (and shared.js) then.
Author
Owner

@DavidAnson commented on GitHub (Apr 15, 2019):

@byzyk: Still interested in putting your rule implementation into the core? I just accepted another PR for a new rule, and am open to yours as well. :)

<!-- gh-comment-id:483109138 --> @DavidAnson commented on GitHub (Apr 15, 2019): @byzyk: Still interested in putting your rule implementation into the core? I just accepted another PR for a new rule, and am open to yours as well. :)
Author
Owner

@byzyk commented on GitHub (Apr 27, 2019):

Hi @DavidAnson, sorry for a bit of a delay

Yes totally! Is there anything I should note before submitting a PR? I assume you'd expect tests for the rule, right?

<!-- gh-comment-id:487272257 --> @byzyk commented on GitHub (Apr 27, 2019): Hi @DavidAnson, sorry for a bit of a delay Yes totally! Is there anything I should note before submitting a PR? I assume you'd expect tests for the rule, right?
Author
Owner

@DavidAnson commented on GitHub (Apr 27, 2019):

Cool! I’ve been changing the coding style of rules slightly, so please have a look in the next branch to see what I mean. There are two new rules there (one from a contributor) that may be helpful. I’d ask that you send your PR from that branch and, yes, we will need tests before it ultimately goes in. :) It’s pretty quick and easy to add tests for most rules, so I hope that won’t be a big investment. Thanks for your help!

PS - I’m thinking to release soon, so if you have something in the next few days it can be in this release. If not, that’s totally fine!

<!-- gh-comment-id:487300477 --> @DavidAnson commented on GitHub (Apr 27, 2019): Cool! I’ve been changing the coding style of rules slightly, so please have a look in the `next` branch to see what I mean. There are two new rules there (one from a contributor) that may be helpful. I’d ask that you send your PR from that branch and, yes, we will need tests before it ultimately goes in. :) It’s pretty quick and easy to add tests for most rules, so I hope that won’t be a big investment. Thanks for your help! PS - I’m thinking to release soon, so if you have something in the next few days it can be in this release. If not, that’s totally fine!
Author
Owner

@byzyk commented on GitHub (May 13, 2019):

Hi @DavidAnson, thanks for your guidance, it's really helpful but unfortunately I'm totally swamped at work atm, so not sure on when will I have time to take care of this. Hopefully in a month or so 🤞🏽

<!-- gh-comment-id:491799327 --> @byzyk commented on GitHub (May 13, 2019): Hi @DavidAnson, thanks for your guidance, it's really helpful but unfortunately I'm totally swamped at work atm, so not sure on when will I have time to take care of this. Hopefully in a month or so 🤞🏽
Author
Owner

@DavidAnson commented on GitHub (May 13, 2019):

Whenever you’re ready!

<!-- gh-comment-id:491832253 --> @DavidAnson commented on GitHub (May 13, 2019): Whenever you’re ready!
Author
Owner

@TheJaredWilcurt commented on GitHub (Aug 25, 2019):

Also excitedly waiting for this. Especially for enforcing _text_ to be *text*.

<!-- gh-comment-id:524657706 --> @TheJaredWilcurt commented on GitHub (Aug 25, 2019): Also excitedly waiting for this. Especially for enforcing `_text_` to be `*text*`.
Author
Owner

@mkistler commented on GitHub (Aug 8, 2021):

I was looking for a rule/rules very much like this. To be specific, the rule(s) I want are:

  • For italics use single _ never single *
  • For bold use double * never double _

It would be great to have these in the base package!

<!-- gh-comment-id:894780830 --> @mkistler commented on GitHub (Aug 8, 2021): I was looking for a rule/rules very much like this. To be specific, the rule(s) I want are: - For italics use single _ never single * - For bold use double * never double _ It would be great to have these in the base package!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/markdownlint#1978
No description provided.