[GH-ISSUE #298] No-wrapping—opposite of line length rule MD013

kerem commented

2026-03-03 01:25:09 +03:00

Owner

Originally created by @mrmanc on GitHub (Jun 19, 2020).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/298

I’m working on a change to MD013 in the Ruby markdownlint project and I’m keen to make the same change to this project since it is this one I actually use. Would you be happy for me to have a go at porting the same change over?

Originally created by @mrmanc on GitHub (Jun 19, 2020). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/298 I’m working on a [change to MD013 in the Ruby markdownlint project](https://github.com/markdownlint/markdownlint/issues/317) and I’m keen to make the same change to this project since it is this one I actually use. Would you be happy for me to have a go at porting the same change over?

kerem added the

new rule

label

2026-03-03 01:25:09 +03:00

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 19, 2020):

I am open to the idea, yes! I would prefer to be consistent across the two projects. However, you will see that this project‘s implementation of the rule already offers additional options over what’s available in the Ruby implementation. It would be nice to reconcile that before committing to either repository so at least the new option is consistent. I don’t mind subsets, but I would prefer to avoid two different ways of expressing the same behavior. Could you share your thoughts about what you think this might look like?

@DavidAnson commented on GitHub (Jun 19, 2020): I am open to the idea, yes! I would prefer to be consistent across the two projects. However, you will see that this project‘s implementation of the rule already offers additional options over what’s available in the Ruby implementation. It would be nice to reconcile that before committing to either repository so at least the new option is consistent. I don’t mind subsets, but I would prefer to avoid two different ways of expressing the same behavior. Could you share your thoughts about what you think this might look like?

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 19, 2020):

Having looked at the Ruby PR a little more, I think it would be ideal to support the proposed behavior in addition to allowing sentence-based wrapping as referenced in the other issue Jay identified. Forcing entire paragraphs on to a single line seems less desirable to me then putting each sentence on its own line. The latter is what I’ve done when writing my blog for about a decade. Adding both at once may help reconcile them with the various approaches that are available today.

@DavidAnson commented on GitHub (Jun 19, 2020): Having looked at the Ruby PR a little more, I think it would be ideal to support the proposed behavior in addition to allowing sentence-based wrapping as referenced in the other issue Jay identified. Forcing entire paragraphs on to a single line seems less desirable to me then putting each sentence on its own line. The latter is what I’ve done when writing my blog for about a decade. Adding both at once may help reconcile them with the various approaches that are available today.

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@mrmanc commented on GitHub (Jun 23, 2020):

Thanks for your input. Apologies for the slow response.

Could you share your thoughts about what you think this might look like?

I think you’ve seen this from the other PR now, but let me know if you want me to go into any more detail.

I think it would be ideal to support the proposed behavior in addition to allowing sentence-based wrapping as referenced in the other issue Jay identified.

Agreed. I’ve asked how they would like me to contribute that change over there, so once I’m done with that I can ping you on here? Do you have any more input into what you would like to be supported? Are there any other modes you’d want to consider? I see https://cirosantilli.com/markdown-style-guide/#option-wrap-inner-sentence but I can’t imagine that being very important to support.

@mrmanc commented on GitHub (Jun 23, 2020): Thanks for your input. Apologies for the slow response. > Could you share your thoughts about what you think this might look like? I think you’ve seen this from the other PR now, but let me know if you want me to go into any more detail. > I think it would be ideal to support the proposed behavior in addition to allowing sentence-based wrapping as referenced in the other issue Jay identified. Agreed. I’ve asked how they would like me to contribute that change over there, so once I’m done with that I can ping you on here? Do you have any more input into what you would like to be supported? Are there any other modes you’d want to consider? I see https://cirosantilli.com/markdown-style-guide/#option-wrap-inner-sentence but I can’t imagine that being very important to support.

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 23, 2020):

I think one challenge is how to configure the rule. The Node implementation already has strict and stern booleans. The first made sense to add that way and the second was done for consistency, but with more modes being added, I think a style property as you have done makes the most sense. The existing default and properties need to be maintained for backwards compatibility, but I suggest we add all the functionality under the new style parameter.

I propose the following values:

space (default, first space after 80)
strict (nothing beyond 80)
stern (only beyond 80 if no spaces)
single (no wrapping, single line - NEW)
sentence (break after period, etc - NEW)
semantic (https://sembr.org/, UNSUPPORTED for now)

Ideally these names would match with whatever is implemented by the Ruby version.

Also, I should warn you in advance that I will be pretty picky about how this is done, so if you don’t want to deal with that you might want to wait for me to implement this. :)

@DavidAnson commented on GitHub (Jun 23, 2020): I think one challenge is how to configure the rule. The Node implementation already has `strict` and `stern` booleans. The first made sense to add that way and the second was done for consistency, but with more modes being added, I think a `style` property as you have done makes the most sense. The existing default and properties need to be maintained for backwards compatibility, but I suggest we add all the functionality under the new `style` parameter. I propose the following values: - space (default, first space after 80) - strict (nothing beyond 80) - stern (only beyond 80 if no spaces) - single (no wrapping, single line - NEW) - sentence (break after period, etc - NEW) - semantic (https://sembr.org/, UNSUPPORTED for now) Ideally these names would match with whatever is implemented by the Ruby version. Also, I should warn you in advance that I will be pretty picky about how this is done, so if you don’t want to deal with that you might want to wait for me to implement this. :)

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@mrmanc commented on GitHub (Jul 6, 2020):

I would prefer to be consistent across the two projects

Consistency is a win in my book 😃

I think it would be ideal to support the proposed behavior in addition to allowing sentence-based wrapping as referenced in the other issue Jay identified

Supporting sentence-based wrapping makes sense to me.

The Node implementation already has strict and style booleans.

Did you mean strict and stern booleans? This has been confusing me, as I couldn’t see an existing style option.

Also, I should warn you in advance that I will be pretty picky about how this is done, so if you don’t want to deal with that you might want to wait for me to implement this. :)

I’m very comfortable with picky, but thanks for the warning. Happy to follow existing conventions etc and take constructive criticism, so long as it’s kind and takes into account that these aren’t languages I use regularly 😃

I’m going to make a start adding functionality via the Ruby PR. I’ll try to start by establishing parity with the strict and stern functionality currently missing there.

space (default, first space after 80)
strict (nothing beyond 80)
stern (only beyond 80 if no spaces)
single (no wrapping, single line - NEW)
sentence (break after period, etc - NEW)

If I understand this correctly, you propose changing not_wrapped to single in the existing PR? Happy to do that. I think you’re also proposing changing wrapped to strict? I need to check the details of what the current functionality is to check that it would match strict.

semantic (https://sembr.org/, UNSUPPORTED for now)

Wow, that is an interesting idea. Kinda glad I asked now! No idea how semantic would be supported, other than maybe not imposing any style?

Supplemental: should society surmise supplemental style strings should solely start s? 😃

@mrmanc commented on GitHub (Jul 6, 2020): > I would prefer to be consistent across the two projects Consistency is a win in my book 😃 > I think it would be ideal to support the proposed behavior in addition to allowing sentence-based wrapping as referenced in the other issue Jay identified Supporting sentence-based wrapping makes sense to me. > The Node implementation already has strict and style booleans. Did you mean `strict` and `stern` booleans? This has been confusing me, as I couldn’t see an existing `style` option. > Also, I should warn you in advance that I will be pretty picky about how this is done, so if you don’t want to deal with that you might want to wait for me to implement this. :) I’m very comfortable with picky, but thanks for the warning. Happy to follow existing conventions etc and take constructive criticism, so long as it’s kind and takes into account that these aren’t languages I use regularly 😃 I’m going to make a start adding functionality via the Ruby PR. I’ll try to start by establishing parity with the `strict` and `stern` functionality currently missing there. > space (default, first space after 80) > strict (nothing beyond 80) > stern (only beyond 80 if no spaces) > single (no wrapping, single line - NEW) > sentence (break after period, etc - NEW) If I understand this correctly, you propose changing `not_wrapped` to `single` in the existing PR? Happy to do that. I think you’re also proposing changing `wrapped` to `strict`? I need to check the details of what the current functionality is to check that it would match `strict`. > semantic (https://sembr.org/, UNSUPPORTED for now) Wow, that is an interesting idea. Kinda glad I asked now! No idea how `semantic` would be supported, other than maybe not imposing any style? Supplemental: should society surmise supplemental style strings should solely start `s`? 😃

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jul 6, 2020):

Did you mean strict and stern booleans?

Yes, sorry for the typo.

If I understand this correctly, you propose changing not_wrapped to single in the existing PR?

Right.

I think you’re also proposing changing wrapped to strict?

I think the current/default/original behavior maps to what I called “space“ in my list above. I’ve always found it a little bit confusing, but maintained the default and behavior for consistency.

No idea how semantic would be supported

I think it would be a challenge which is why I propose we not deal with it right now.

Supplemental: should society surmise supplemental style strings should solely start s?

That was an accident, but now that you point it out, I think it should be codified into law!

@DavidAnson commented on GitHub (Jul 6, 2020): > Did you mean strict and stern booleans? Yes, sorry for the typo. > If I understand this correctly, you propose changing not_wrapped to single in the existing PR? Right. > I think you’re also proposing changing wrapped to strict? I think the current/default/original behavior maps to what I called “space“ in my list above. I’ve always found it a little bit confusing, but maintained the default and behavior for consistency. > No idea how semantic would be supported I think it would be a challenge which is why I propose we not deal with it right now. > Supplemental: should society surmise supplemental style strings should solely start s? That was an accident, but now that you point it out, I think it should be codified into law!

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jul 6, 2020):

Did you mean strict and stern booleans?

Yes, sorry for the typo.

I’ve corrected this in my post above to avoid confusing anyone else.

@DavidAnson commented on GitHub (Jul 6, 2020): > > Did you mean strict and stern booleans? > Yes, sorry for the typo. I’ve corrected this in my post above to avoid confusing anyone else.

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@bnb commented on GitHub (Aug 11, 2020):

Huge +1.

@bnb commented on GitHub (Aug 11, 2020): Huge +1.

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@OsirisTerje commented on GitHub (Dec 3, 2023):

@mrmanc Anything happening with this rule ? Would love to see this, like expressed in #502 . Or is this issue fixed by #319 (other repo though) ?

@OsirisTerje commented on GitHub (Dec 3, 2023): @mrmanc Anything happening with this rule ? Would love to see this, like expressed in [#502](https://github.com/DavidAnson/markdownlint/issues/502) . Or is this issue fixed by [#319](https://github.com/markdownlint/markdownlint/pull/319) (other repo though) ?

kerem commented

2026-03-03 01:25:10 +03:00

Author

Owner

@neumaerker-qm commented on GitHub (Apr 15, 2024):

In our company we set line_length to 250 characters, but it is to short for some sentence I have to write. It is only one sentence with a period at the end. Can I make use of single (no wrapping, single line - NEW)or sentence (break after period, etc - NEW) and how?

@neumaerker-qm commented on GitHub (Apr 15, 2024): In our company we set line_length to 250 characters, but it is to short for some sentence I have to write. It is only one sentence with a period at the end. Can I make use of `single (no wrapping, single line - NEW)`or `sentence (break after period, etc - NEW)` and how?

kerem commented

2026-03-03 01:25:11 +03:00

Author

Owner

@jannis-baum commented on GitHub (Jun 2, 2025):

Also, I should warn you in advance that I will be pretty picky about how this is done, so if you don’t want to deal with that you might want to wait for me to implement this. :)

@DavidAnson Any updates on this?

@jannis-baum commented on GitHub (Jun 2, 2025): > Also, I should warn you in advance that I will be pretty picky about how this is done, so if you don’t want to deal with that you might want to wait for me to implement this. :) @DavidAnson Any updates on this?

kerem commented

2026-03-03 01:25:11 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 2, 2025):

Nope

@DavidAnson commented on GitHub (Jun 2, 2025): Nope

kerem referenced this issue

2026-03-07 20:04:13 +03:00

[GH-ISSUE #255] Inline rule ignore #2065

Rows
Columns

[GH-ISSUE #298] No-wrapping—opposite of line length rule MD013 #255