FR: Support baskslash `\` at line ending to insert line break

[redactedscribe]

Is Your Feature Request Related to a Problem? Please Describe.

Apparently CommonMark supports this (although I only read this from a comment online), but using a backslash is something I've previously used to insert line breaks using some Markdown tools, like VS Code (I believe it supports it by default rather it than being some extension I have). I'm wondering why backslash line breaks are not supported by the Linter.

Describe the Solution You'd Like

foo \ -> foo<br> bar\ -> bar<br>

Please include an example where applicable:

Hello \
World

Lints as:

Hello \

World

Ideally would lint as:

Hello \
World

Describe Alternatives You've Considered

Just using two spaces instead of a backslash.

Additional Context

I would prefer to use a backslash due to it being visually obviously that an explicit line break is present. Otherwise it's hard to detect in Obsidian.

Thanks.

[pjkaufman]

I don't think I am familiar with this. I will need to look into it since this is the first I have heard of this being a thing.

[pjkaufman]

Also, @redactedscribe , is this essentially an add-on to #933 or is there something that makes this different than adding an option for what line break value to use? This will help me better understand what to do moving forward.

[redactedscribe]

I don't think I am familiar with this. I will need to look into it since this is the first I have heard of this being a thing.

I was surprised I couldn't find a pre-existing issue.

Also, @redactedscribe , is this essentially an add-on to #933 or is there something that makes this different than adding an option for what line break value to use? This will help me better understand what to do moving forward.

It looks like it's essentially the same thing but without mention of \.

Just to state it in my own words: I'd like Linter to treat \ identically to (double space) line endings. I didn't initially think to ask for an option to make line breaks consistent but it makes sense. So, be able to choose the preferred line break , <br>, <br/>, or \ (if you deem backslashes are valid too).

[pjkaufman]

I don't think I am familiar with this. I will need to look into it since this is the first I have heard of this being a thing.

I was surprised I couldn't find a pre-existing issue.

Also, @redactedscribe , is this essentially an add-on to #933 or is there something that makes this different than adding an option for what line break value to use? This will help me better understand what to do moving forward.

It looks like it's essentially the same thing but without mention of \.

Just to state it in my own words: I'd like Linter to treat \ identically to (double space) line endings. I didn't initially think to ask for an option to make line breaks consistent but it makes sense. So, be able to choose the preferred line break , <br>, <br/>, or \ (if you deem backslashes are valid too).

To clarify, are you saying that you would expect the two trailing spaces to replace values like , <br>, and <br/> with \ if there was an option to set the line ending indicator? I ask because that is possible, but may change how things would be implemented.

[redactedscribe]

To clarify, are you saying that you would expect the two trailing spaces to replace values like , <br>, and <br/> with \ if there was an option to set the line ending indicator? I ask because that is possible, but may change how things would be implemented.

What I expect is that if a line ends with two spaces and I've defined two spaces as my preferred line break syntax, then any line ending with the any of the alternatives, i.e. a backslash or the BRs, would get converted to double spaces.

If instead backslash \ was my preference, convert all alternatives to \. If I have no preferred line break syntax set, do not try and make line breaks consistent.

Double spaces, BRs, and backslash would ideally all be supported as valid line break syntax at the end of a line.

[pjkaufman]

I did start work on this before I got sick and then distracted with other tasks. I will need to see how far in I got on this since this affects several different rules and may not be easy to gauge what all has been affected.

If I were to proceed with this and put out a beta release for this would you be interested in testing it via BRAT @redactedscribe ?

[redactedscribe]

I've not used BRAT before but I'm guessing it's easy enough. Any reason why its better than being provided a zip of the file? I'm willing to help nonetheless.

this affects several different rules and may not be easy to gauge what all has been affected.

Shouldn't your tests catch these things? Just assuming here.

[pjkaufman]

I've not used BRAT before but I'm guessing it's easy enough. Any reason why its better than being provided a zip of the file? I'm willing to help nonetheless.

BRAT is simpler as I can create a release and get more eyes on it than having to create a zip for a single issue. Though for smaller things with faster responses, a zip makes more sense when less people are to be involved.

this affects several different rules and may not be easy to gauge what all has been affected.

Shouldn't your tests catch these things? Just assuming here.

It would be great if tests caught these things. But as a dev I have a very different view on how to use rules together and what rules actually get used. It seems more often than not, when the complexity increases, the scenarios I think are relavent do not cover what users will try.

[pjkaufman]

I went ahead and merged the PR for these changes. I plan to make a release later this week, but we will see if that pans out.

Please let us know if there is an issue with this on master or in the next release.