Yeah, this is not a good way to do this. Think about how people are using comments-- pasting debug output. Sometimes that debug output can be many lines. I don't want to go through and put something at the end of every line.
Quite possibly the most stupid design decision ever, given we've had a long time of people quite happily accepting the idea of a line break meaning there will be a new line. Reflavouring the markdown so it matches users' expectations and functions intuitively is the correct fix, not using the horribly hacky "two spaces for a clear line break" the creator chose. It'd be like saying we need to pronounce gif as jif.
This is stupid. Nobody wants to reformat copy&pasted text, and regardless it needs to be intuitive. If Markdown has a default behaviour we don't like, Bitbucket should make it configurable in Markdown and change the default configuration. If Markdown doesn't already have some sense of text context, it is worth giving it one.
Jeffrey Kranenburg I think it simply is counter-intuitive. 90% of the developers I work with know markdown from GitHub, where it works like you expect it. Every person we try to work with is having problems when using BitBucket issues because of the line breaks. You have to explain to them they need to use double spaces on each line break.
Especially when trying to copy/paste text into the editor; it's different if you get an unformatted result vs a completely different result because all of your line break get lost.
"A markup should not break elementary common sense rules in order to provide other elevated functionality."
This is just bad user experience and if this "is how markdown works", maybe markdown isn't that great for an issue tracker. Which might be the reason companies like GitHub customized it to match the requirements better - and Bitbucket should do the same or embed a better suited alternative to markdown.
I gave it a go, but I really I can't understand this design decision. If a user has to search Google, find a bug logged against the product, and read the resolution in order to figure out how to use a line feed, doesn't the feel like an inefficient design that would lead to a less than ideal user experience? This sort of situation isn't isolated to this specific example.
A bit of unsolicited advice: From a user experience initiative, it might be a good idea to take a look at the number of view hits on "resolved" issues, and take another look at improving the resolution for those that are high on the list.
PS - it's also worth noting that bitbucket is kind enough to import a texty version of the changelogs into a Pull Request, which includes 4 spaces at the beginning of lines that fall under each commit. If there was any way bitbucket could automatically interpret these 4 spaces (which are always after a CR) as an instruction to display a CR on the pull request page, instead of removing the CR that is mid-paragraph, that would make it look awesome and be fully automatic.
I agree, this is ridiculous. I've spent 20 minutes so far trying to get that to work in a code block and nada. One would expect this to work just like markdown, CR/LF/CRLF at the end of the line breaks to the new line. This can't be a hard fix.
For what it's worth, after 28 minutes, I gave up and attached a screen shot.