FR: Treat content before <br> as a line's end and run line ending rules based on that

[redactedscribe]

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

When editing a table using live preview mode, two presses of Return inserts a new paragraph for a cell, represented as <br><br> in the source. If any spaces were pre the <br><br> they would not be removed by rules relating to line endings, e.g. trailing spaces.

Describe the Solution You'd Like

A clear and concise description of what you want to happen.

Please include an example where applicable:

Foo text. <br><br>Bar text.

Foo text.<br><br>Bar text.

Describe Alternatives You've Considered

-

Additional Context

The linter would have to account for lines with multiple "line endings", because a single line could now be foo $<br>bar$<br>baz. $, with $ representing each line ending to consider (in this case, I'd want the space after foo and baz. to be stripped).

After writing this, it looks like this is related to #933.

Thanks.

[pjkaufman]

Hey @redactedscribe , could you provide a list of rules you would expect this to affect. I am thinking about how this might work, but every time I think about this it just ends up turning into more of a nightmare logically accounting for multiple lines on a single line. This is because a lot of the logic uses regex to finds things to update which would not be able to account for multiple lines on one line.

[redactedscribe]

The example code I gave isn't particularly useful because the rendered output strips the trailing space anyway I believe (can't select the trailing space with the cursor at least). But so what if it doesn't strip it? It's invisible. The benefit here is really only in the source which I think reduces how important this feature is to some extent. I should think of a better example.

As for which rules it may affect, I'd need to look, but I can't promise I'll be able to help. This exercise could produce a better example and therefore a better reason to pursue this feature.

I do have a suggestion though:

What if the source was converted into a temporary "expanded" version, i.e. so <br>s become newlines? Then the rules could be run as-is without any complex new logic. After running, the newlines would be converted back to <br>s to produce the final result. Would that be effective? Thinking about it in the context of a table, those newlines would break the table in the temporary source...

[pjkaufman]

Unless there is a way to expand and collapse them without breaking the original source formatting, it is not worth converting new line indicators to new line characters especially if whitespace gets trimmed in some way and now I cannot undo the expansion.

Though I will say, tables should be getting ignored by a lot of formatting rules because they brake tables.