-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should not convert a line break (two spaces) to <br> #24
Comments
Just saw that it converts the line breaks to |
Any news on this? Conversion to |
Sorry for not replying earlier. The reason why it converts trailing whitespace into a # test
this first line may or may not have trailing whitespace
which may or may not cause a break before this line Maybe even screen-shot it, or print it out and try to tell what the author intended. Over all, using trailing whitespace to indicate document layout is just a really bad syntax feature. I can see the issue; The main use-case is text that is formatting-sensitive, but isn't code, like addresses or poems. I do agree that the following example isn't quite right. 221B Baker St<br>London, NW1 6XE<br>England We should change the styleguide to make it look like this: 221B Baker St<br>
London, NW1 6XE<br>
England |
Okay, your arguments make sense. However I find it much more ugly to have HTML code in MD files than having to look at second time at a line to see whether it wraps. Especially as I use markdown preview anyway this does not matter for me. Sentence finished.
We continue on a new line... You already see the line break, because after Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec a diam lectus.
Sed sit amet ipsum mauris. Maecenas congue ligula ac quam viverra nec
consectetur ante hendrerit. Donec et mollis dolor. Praesent et diam eget libero
egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem
lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean ut gravida
lorem. Ut turpis felis, pulvinar a semper sed, adipiscing id dolor.
Pellentesque auctor nisi id magna consequat sagittis. Curabitur dapibus enim sit
amet elit pharetra tincidunt feugiat nisl imperdiet. Ut convallis libero in urna
ultrices accumsan. Donec sed odio eros. Donec viverra mi quis quam pulvinar at
malesuada arcu rhoncus. Cum sociis natoque penatibus et magnis dis parturient
montes, nascetur ridiculus mus. In rutrum accumsan ultricies. Mauris vitae nisi
at sem facilisis semper ac in est. Obviously in this large text you should use a new line anyway (to clearly show it as two paragraphs), but this is just for demonstrating purposes. |
@slang800 While I don't mean to be rude, I really don't agree with adding HTML of any sort automatically with a tidying algorithm like this. Markdown is meant to be expressive and readable in plain text, as well as being easily converted to HTML for even better formatting. The double space at the end of a line is invisible on purpose, because it is a hint to the md interpreter, not a visual cue that readers/writers need in plain text. The only time it matters for seeing this in the plain text is if somebody did it accidentally, and doesn't actually want a |
👍 |
Except, in certain situations, you can't even check to see if there is trailing whitespace... Like when code is printed or displayed on a screen statically. That's what makes trailing whitespace such an awful syntactical element.
I don't think that we should assume people are using Atom to read all files... I frequently need to edit files over SSH without a nice editor like Atom.
Usually "more reads than writes" is an argument for not using shorthands and making code as explicit as possible. If we're optimizing for readability, then shouldn't we be trying to prevent all confusion, even if it makes the code a bit uglier?
That's only obvious if you're looking at the rendered text on a wide enough display. If you're just proofreading the markdown source (such as during code reviews) then that's very easy to miss.
"Clearly"?! It looks like "Pellentesque" just got wrapped to the next line because it's a long word.
I agree, and I think that the use of
No worries - I'd much rather get "hurt feelings" than let a bad design decision go unnoticed. 😄
Maybe I'm more concerned about formatting than the average user, or maybe I just run into badly-formatted documents more often than is normal... But, when I'm writing something, I try to layout my text very carefully. Each element is there for a reason and line-breaks are rarely needed. I think I've run into them on accident more often than they're used on purpose. If we were talking about the kerning on text, or how words should be hyphenated, I'd consider it a "hint". However, line-breaks are much more important than that. A linebreak is there to interrupt the normal flow of text, without starting a new paragraph / idea. It brings the focus away from the organization of a work in terms of paragraphs and sentences and down to the arrangement of words on a line - a level of control that's usually reserved for poetry or song lyrics.
How does that make it more difficult? |
I think that it makes it more difficult due to the fact that a line break was intended, but instead, I end up with a single line ( with In fact, I would argue that newlines should not be altered when immediately followed by text (with or without the double space), again for plain text readability. Other people will likely look at md files in another text editor, and I may want to end my lines at 80 characters for easy reading. |
Oh, yes - I agree, and that's fixed in notslang/tidy-markdown#26 (it breaks the line after the
I actually don't keep any information about the original line-breaks. The document gets reformatted entirely to maintain consistency and give a single representation for any given text. However, I have tried using an 80-character hard-wrap... Most people hated it (which I suppose should have been obvious from surveying the way that people tend to format their Markdown) and maintaining that hard-wrap without a nice editor to automatically reflow the text was a huge pain. Also, the diffs that it produced were horrendous; a single word being added to the beginning of a paragraph would result in 2-3 lines after it being changed. |
I think adding HTML in any form is a no-go. It breaks conversion to pdf or other formats with pandoc, as Apart from that, markdown is supposed to be readable in plain text, and having the absolute minimum markdown. Adding a An option to disable all html "hacks" would be enough though. Maybe those hacks are good when your only intent is rendering HTML, and you don't need to constantly read and interact with the markdown source without rendering it. |
Really? Did not knew this. |
@Rubk Yes, here is an example of the outputs when tunning
|
Thanks for the visual representation @DamianPereira. I hope this is finally a convincing argument for @slang800. |
With markdown you can force a line break with 2 spaces at the end of the line. However your package deletes these while tidying up:
# test This is a line break without spaces new line - at the end of this line are 2 spaces this line should be broke up.
The text was updated successfully, but these errors were encountered: