I'd prefer a warning that shows up below the preview, maybe to the left of the "Post comment" button. I'm not a huge fan of systems that change my data because they think they are smarter than me.
I'd prefer a warning that shows up below the preview, maybe to the left of the "Post comment" button. I'm not a huge fan of systems that change my data because they think they are smarter than me.
I feel like the better fix for this would just be to add some optional markdown buttons, it's what users who aren't familiar with the syntax are used to on every other website.
I feel like the better fix for this would just be to add some optional markdown buttons, it's what users who aren't familiar with the syntax are used to on every other website.
Seems like you would just add something similar to markdown = markdown.replace(r"(\(.*\)\[.*\])", r"(\[.*\]\(.*\))") in that method. Can't remember if you need to do anything special to save the...
Seems like you would just add something similar to
Yeah, this is exactly why these fixes can be trickier than they seem. There's some "context" you need to account for, where you don't want to do replacements inside code sections and some other...
Yeah, this is exactly why these fixes can be trickier than they seem. There's some "context" you need to account for, where you don't want to do replacements inside code sections and some other places.
It's still possible, but would probably need to be done in the "post-processing" step instead, where you're modifying the generated HTML (as opposed to "pre-processing" and modifying markdown). That way you can avoid certain contexts by skipping over tags. That's how Tildes currently does some custom things like linkifying usernames (@Deimos) and groups (~tildes), because you wouldn't want those to happen inside code blocks and such either.
I think breaking whatever flavor of Markdown spec that has been adopted is generally a bad idea. If users are entering Markdown source, they should be expected to enter syntactically correct...
I think breaking whatever flavor of Markdown spec that has been adopted is generally a bad idea. If users are entering Markdown source, they should be expected to enter syntactically correct Markdown. The case of user and group mentions is not a native Markdown feature, but it’s also not intended to fix a mistaken input, so I can see the argument for it. I don’t think it’s too much to ask of users to enter correct Markdown, given there is a preview option and formatting help buttons above every comment input field, so you can easily tell if your comment source is correct before posting, and you can teach yourself the correct syntax when you get it wrong. However, if you deem it that users shouldn’t be expected to enter correct Markdown source, then I believe the correct course of action is to implement a WYSIWYG comment editor.
That's my feeling too. I understand the desire to lower the barrier to entry, but I also feel it's not a good idea to reinforce invalid markdown as being accepted. That'll just set people down the...
That's my feeling too. I understand the desire to lower the barrier to entry, but I also feel it's not a good idea to reinforce invalid markdown as being accepted. That'll just set people down the wrong path when they try using markdown in other contexts.
Not related to topic, hope you don't mind. Tildes markup changes links with or without https:// part. However only https:// links work, like this >Wikipedia. A link without https:// part gets...
Not related to topic, hope you don't mind. Tildes markup changes links with or without https:// part. However only https:// links work, like this >Wikipedia. A link without https:// part gets converted but doesn't work >> Wikipedia. This link appends tildes.net in the url. It's would be better if links without https part remain in plain markup.
I made a post earlier about this but deleted it as it is default behaviour in CommonMark. I see it's possible to change this so maybe this be considered too.
There's an issue in the tracker for this: https://gitlab.com/tildes/tildes/-/issues/685 I think it should be reasonable to fix, and I posted a comment in there explaining how it would probably...
Personally I'd prefer an indicator that the syntax is wrong rather than having the syntax automatically fixed. That way people are given the opportunity to fix it themselves, making it more likely...
Personally I'd prefer an indicator that the syntax is wrong rather than having the syntax automatically fixed. That way people are given the opportunity to fix it themselves, making it more likely they'll remember the correct way next time.
Indicators like that in IDEs have been super helpful for me when writing unfamiliar code because it becomes a little challenge to learn how to write code the right way and not trigger the indicator.
Might also help to have the "Formatting help" link display an abbreviated list of common markdown snippets (links, bold, italic, a heading or two) without leaving the page, with an option to click into the full help page.
Also, if an url ends in a closing ), like wikipedia does, can we make it so it fixes that if it happens? I think it's fixed by making it turn [text](website.com/(article)) into...
Also, if an url ends in a closing ), like wikipedia does, can we make it so it fixes that if it happens?
I think it's fixed by making it turn [text](website.com/(article)) into [text](website.com/(article\)), not sure though.
It took me a while not to enter it backwards. Also, the punctuation is a bit annoying to enter on a mobile keyboard, so I think an “insert link” button might be better.
It took me a while not to enter it backwards. Also, the punctuation is a bit annoying to enter on a mobile keyboard, so I think an “insert link” button might be better.
This is why I think Markdown is fucking stupid, and why I won't implement it except as an optional, user-enabled add-on in my project. If a formatting standard fucks up the output in unexpected...
This is why I think Markdown is fucking stupid, and why I won't implement it except as an optional, user-enabled add-on in my project.
If a formatting standard fucks up the output in unexpected ways more often than not, it shouldn't be used.
It is a design flaw of Markdown, though. Symbols aren't that memorable. Especially not two flavors of braces in a specific order. It's a recipe for small, inconvenient mistakes.
It is a design flaw of Markdown, though. Symbols aren't that memorable. Especially not two flavors of braces in a specific order. It's a recipe for small, inconvenient mistakes.
Thank you for sharing this info. I haven't heard of most of these languages, and will look through the list, since I'm looking for one for my project. I would consider a LML to be non-stupid if...
Thank you for sharing this info. I haven't heard of most of these languages, and will look through the list, since I'm looking for one for my project.
I would consider a LML to be non-stupid if only a very small portion of user-input texts come out in a way where the user says, "that's not what I was expecting to happen"
I'd prefer a warning that shows up below the preview, maybe to the left of the "Post comment" button. I'm not a huge fan of systems that change my data because they think they are smarter than me.
I feel like the better fix for this would just be to add some optional markdown buttons, it's what users who aren't familiar with the syntax are used to on every other website.
Seems like you would just add something similar to
markdown = markdown.replace(r"(\(.*\)\[.*\])", r"(\[.*\]\(.*\))")in that method.
Can't remember if you need to do anything special to save the captured text or not.
Yeah, this is exactly why these fixes can be trickier than they seem. There's some "context" you need to account for, where you don't want to do replacements inside code sections and some other places.
It's still possible, but would probably need to be done in the "post-processing" step instead, where you're modifying the generated HTML (as opposed to "pre-processing" and modifying markdown). That way you can avoid certain contexts by skipping over tags. That's how Tildes currently does some custom things like linkifying usernames (@Deimos) and groups (~tildes), because you wouldn't want those to happen inside code blocks and such either.
I think breaking whatever flavor of Markdown spec that has been adopted is generally a bad idea. If users are entering Markdown source, they should be expected to enter syntactically correct Markdown. The case of user and group mentions is not a native Markdown feature, but it’s also not intended to fix a mistaken input, so I can see the argument for it. I don’t think it’s too much to ask of users to enter correct Markdown, given there is a preview option and formatting help buttons above every comment input field, so you can easily tell if your comment source is correct before posting, and you can teach yourself the correct syntax when you get it wrong. However, if you deem it that users shouldn’t be expected to enter correct Markdown source, then I believe the correct course of action is to implement a WYSIWYG comment editor.
That's my feeling too. I understand the desire to lower the barrier to entry, but I also feel it's not a good idea to reinforce invalid markdown as being accepted. That'll just set people down the wrong path when they try using markdown in other contexts.
Not related to topic, hope you don't mind. Tildes markup changes links with or without https:// part. However only https:// links work, like this >Wikipedia. A link without https:// part gets converted but doesn't work >> Wikipedia. This link appends tildes.net in the url. It's would be better if links without https part remain in plain markup.
I made a post earlier about this but deleted it as it is default behaviour in CommonMark. I see it's possible to change this so maybe this be considered too.
Thanks. I totally missed that. Any reason why this happens? It's same on Firefox and Chrome so I think it's a normal thingy for all browsers.
There's an issue in the tracker for this: https://gitlab.com/tildes/tildes/-/issues/685
I think it should be reasonable to fix, and I posted a comment in there explaining how it would probably need to be done.
Personally I'd prefer an indicator that the syntax is wrong rather than having the syntax automatically fixed. That way people are given the opportunity to fix it themselves, making it more likely they'll remember the correct way next time.
Indicators like that in IDEs have been super helpful for me when writing unfamiliar code because it becomes a little challenge to learn how to write code the right way and not trigger the indicator.
Might also help to have the "Formatting help" link display an abbreviated list of common markdown snippets (links, bold, italic, a heading or two) without leaving the page, with an option to click into the full help page.
Also, if an url ends in a closing ), like wikipedia does, can we make it so it fixes that if it happens?
I think it's fixed by making it turn
[text](website.com/(article))into[text](website.com/(article\)), not sure though.It works normal. No need to add \. Just )) will work. Like this Batman
well that's new to me!
It took me a while not to enter it backwards. Also, the punctuation is a bit annoying to enter on a mobile keyboard, so I think an “insert link” button might be better.
This is why I think Markdown is fucking stupid, and why I won't implement it except as an optional, user-enabled add-on in my project.
If a formatting standard fucks up the output in unexpected ways more often than not, it shouldn't be used.
It is a design flaw of Markdown, though. Symbols aren't that memorable. Especially not two flavors of braces in a specific order. It's a recipe for small, inconvenient mistakes.
I disagree with you.
I think it is Markdown's format which is messing up, not the people who are trying to adhere to it.
Thank you for sharing this info. I haven't heard of most of these languages, and will look through the list, since I'm looking for one for my project.
I would consider a LML to be non-stupid if only a very small portion of user-input texts come out in a way where the user says, "that's not what I was expecting to happen"