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

Three consecutive dots are always read as an ellipsis #5707

Closed
mirh opened this issue Aug 25, 2019 · 7 comments
Closed

Three consecutive dots are always read as an ellipsis #5707

mirh opened this issue Aug 25, 2019 · 7 comments

Comments

@mirh
Copy link

mirh commented Aug 25, 2019

In markdown at least

Just simply write ... in a document, and it magically becomes (or \ldots{} in latex) everywhere else.

@alerque
Copy link
Contributor

alerque commented Aug 26, 2019

This is controlled by the +smart typography extension. You can turn it off for the markdown reader if that's the result you want.

$ pandoc -f markdown -t latex <<< "..."
\ldots{}

$ pandoc -f markdown-smart -t latex <<< "..."
...

Note that by default this extension is usually on for inputs, but outputs have different defaults. LaTeX output for example defaults to on (hence the \ldots{}). In Markdown output on the other hand is off by default, but you can enable it in your output format (-t markdown+smart) to get . This combination of readers and writers both having this extension setting is confusing at first, but play around with it on both ends and maybe use native as an input or an output format to see clearly what is happening with one end specifically.

@mb21
Copy link
Collaborator

mb21 commented Aug 26, 2019

@mb21 mb21 closed this as completed Aug 26, 2019
@mirh
Copy link
Author

mirh commented Aug 26, 2019

:/ I could have swore I had checked docs. Thank you a lot.

p.s. perhaps it could be slightly more underlined how its defaults work

@mb21
Copy link
Collaborator

mb21 commented Aug 26, 2019

No worries, if you're unsure you can also always ask on pandoc-discuss list...

how its defaults work

Well, there is the "enabled by default in" section... but yes, it took me a while to find it as well. If you have a suggestion how to make it more readable, we're all ears :-)

@mirh
Copy link
Author

mirh commented Aug 26, 2019

The "enabled by default" part could be in plain text perhaps, it's too much camouflaged in the "supported formats" list.

Or anyway, it could be put in any such way that it is clear whether (both input and output) refers just to context, or even latex/markdown.

@jgm
Copy link
Owner

jgm commented Aug 26, 2019

In Markdown output on the other hand is off by default, but you can enable it in your output format (-t markdown+smart) to get ….

This isn't quite accurate. The smart extension is enabled by default in markdown, for both input and output. But you have to think about what it means for smart to be enabled for output. It means that we're producing a markdown document which will render properly with the smart option set -- smart typography sensitive markdown. So when we have +smart on output, we render ellipses as three periods .... When we have -smart, on the other hand, it means that we're rendering a markdown document which won't be processed as having smart typography. In that case, we need to render an ellipses as an ellipses character.

In practice, this means that going -f markdown -t markdown will leave ... as ... , which is what we want.

Note also that if you want 3 dots but don't want to mess around with extensions, you can just escape them: \.\.\..

@mb21
Copy link
Collaborator

mb21 commented Aug 26, 2019

Yeah, maybe we could change the manual formatting to:

input formats:
    markdown*, commonmark*, latex*, mediawiki, org, rst, twiki 
output formats:
    markdown*, latex*, context*, rst

* enabled by default

The question is where we put the * enabled by default. At the bottom of every extension? Maybe it's enough to put it in the Extensions top section

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

4 participants