markdownlint icon indicating copy to clipboard operation
markdownlint copied to clipboard

No-wrapping—opposite of line length rule MD013

Open mrmanc opened this issue 4 years ago • 10 comments

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?

mrmanc avatar Jun 19 '20 12:06 mrmanc

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 avatar Jun 19 '20 16:06 DavidAnson

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 avatar Jun 19 '20 19:06 DavidAnson

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 avatar Jun 23 '20 13:06 mrmanc

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 avatar Jun 23 '20 16:06 DavidAnson

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 avatar Jul 06 '20 13:07 mrmanc

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 avatar Jul 06 '20 16:07 DavidAnson

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 avatar Jul 06 '20 19:07 DavidAnson

Huge +1.

bnb avatar Aug 11 '20 16:08 bnb

@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 avatar Dec 03 '23 22:12 OsirisTerje