Skip to content
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

Suggestion: Comments extra #268

Open
Tachytaenius opened this issue Aug 15, 2017 · 2 comments
Open

Suggestion: Comments extra #268

Tachytaenius opened this issue Aug 15, 2017 · 2 comments

Comments

@Tachytaenius
Copy link

(Forgive me if one isn't supposed to put suggestions in issues. Also, forgive me if the metadata extra does this. I thought it did at first but it confused me in such a way that I'm pretty sure it doesn't.)

I suggest a new extra, comments. When used, text surrounded by ~'s then only exists in the output HTML file as being within an HTML comment. You know, <!-- these guys? -->.

Perhaps if there are two tildes surrounding the text then it is removed from the output completely. Like comments for C source code.

Thanks for reading.

@nicholasserra
Copy link
Collaborator

Interesting thought. Sounds useful. What happens currently if you toss html style comments in and convert? Assuming they're transformed into something.

My first concern is whether the ~ is used to indicate anything else in other extras. What if we actually used <!-- as the indicator, with opening and closing, kinda like fenced code blocks work.

@Tachytaenius
Copy link
Author

Tachytaenius commented Apr 30, 2018

I recommend skipping past my verbose reasoning and going to what I propose at the bottom.

Fine! Read it!
...With emphasis-- surrounding with single asterisks-- you create em tags in the output HTML. With raw HTML em tags imitating the output of Markdown emphasis... you also get em tags in the output HTML, 'cause no work is done on raw tags. Same should go for comments: make a shorthand way to write a certain tag (!-- in this case) and don't go against the idea of being able to implement raw HTML within our input just because we can do it shorthand already. Consistency, right?

Now, onto which character we use.
~~ actually does mean strikethrough AFAIK, so that isn't going to work. Sure, maybe you could say that if there's a space between the double tilde and the comment's text it's a comment... but that's horrible.

A nicer idea, whether you agree that "~~ a ~~ vs ~~a~~" is horrid or not, is to use another character! I'd like question marks.

Well, whatever it is... how do we use it? We could take inspiration from headers where they say that one character is a strong heading and two is a weaker one, so for comments that makes ? foo be omitted and ?? foo turn to <!--foo--> although one might have reasons to swap them around. Also, what about comments within a line? Maybe without spaces between the character and the comment's text? Yeah, I know, but this is different: they're both comments, and we're controlling how they interact with newlines.

not comment text

Is how we put comments in code, usually.

Is reminiscent of the use of asterisks for emphasis that we have already!

Then just change the number of question marks to say whether you omit them from the HTML output or change them to <!-- tags.

Also, in regards to using <!-- as the input character, that seems far too clunky to type. Markdown is about flow!

(I'm tired and probably have a huge hole in what I said, but it works in my brain. Trust me!)

RIGHT! Summary.
I propose this:

A fully omitted comment is indicated by a question mark.
A comment that gets converted to and HTML comment is indicated by two question marks.
Having a space after a comment indicator, like with headers, makes markdown2 return to normal text parsing once a newline is reached.
Having no space after, like with emphasis, makes markdown2 return to normal text editing upon reaching the same kind of comment indicator glued-- or rather, not split with a space-- to the other side of the text.

Such that:

normal ?completely omitted comment
completely omitted comment? normal ?? HTML'd comment ?? including those two question marks
??HTML'd comment
HTML'd comment??
normal

...Uh, talks about itself correctly?

I also propose that we allow markdown formatting within the double ('cause singles don't exist in the output, remember?) comments. Backslash escapes have no reason to stop working in there, so it's the
right choice.

phew

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants