asciidoc-py2
asciidoc-py2 copied to clipboard
asciidoc-py
Fix and enhance en/em dash translation
Depending on the back-end being used, -- gets currently translated either to an em dash (HTML, for instance) or an en dash (LaTeX). To allow convenient usage of both types of dashes and resolve this inconsistency, translate (in sync with LaTeX) -- to en dash and --- to em dash.
Well, this will "break" existing documents, of course—the AsciiDoc user guide, for instance.
I'm in favor of this change, and it's been proposed in Asciidoctor as well. See https://github.com/asciidoctor/asciidoctor/issues/1174.
Note that I haven't studied the implementation specifically here, I'm giving :+1: to the idea of supporting both types...however we decide is best.
On 22 November 2014 07:24, Dan Allen [email protected] wrote:
I'm in favor of this change, and it's been proposed in Asciidoctor as well. See asciidoctor/asciidoctor#1174 https://github.com/asciidoctor/asciidoctor/issues/1174.
The idea of being consistent if good, but the idea of breaking every document that uses -- is bad. Any suggestions of how to mitigate the damage?
Cheers Lex
— Reply to this email directly or view it on GitHub https://github.com/asciidoc/asciidoc/pull/50#issuecomment-64040051.
@elextr In Asciidoctor, I plan to tie this feature into the compat-mode setting. With compat-mode on, no breakage, old school behavior. With compat-mode off, you get the new syntax.
Ok, I guess in Asciidoc the only solution is to guard it with an attribute, something like newems. Unfortunately it will have to be set on the command line since the system asciidoc.conf is loaded before the document header.
@christophjaeger pending a better idea, can you implement such an attribute?
Why not use the compat-mode attribute as well? Generally it's better to group new features in bulk or else you end up having a plethora of switches.
Yes.
Given that the Python2 implementation is unlikely to garner a huge number of incompatible changes, gathering them would probably be ok.
Without the asciidoctor heuristic to set the compat-mode attribute it will have to be set by default and users of the new features will have to clear it. That should still be asciidoctor compatible shouldn't it?
I've actually done some of the compat-mode stuff in the AsciiDoc Python compat file already, so you can see the approach I took. It sort of works, but as you mentioned load order is tricky.
https://github.com/asciidoctor/asciidoctor/blob/master/compat/asciidoc.conf#L38
I did the following changes:
- introduced an attribute
compat-mode(that is defined by default and must be undefined to enable the translation as described) as suggested - discarded the documentation changes (should be addressed by a follow-up commit)
I'd like to hold off on integrating this until we get it into Asciidoctor as well so the processors move together on it. I plan to do additional research and add tests to make sure we are hitting all the edge cases. If we discover some additional conditions, we don't want to have to change behavior on users again. Better to do it all at once.
See https://github.com/asciidoctor/asciidoctor/issues/1174 for the related issue.
@christophjaeger It seems this repo will no longer accept PR as the latest release has been cut a while ago but https://github.com/asciidoc/asciidoc-py3 would. If you still want this PR integrated in asciidoc, do you mind pushing it there please? Once done I think you can close this one. Thanks!
Hello, what is the status and likely time frame for a solution about this? I'm eagerly waiting for convenient en-dashes since I started with using AsciiDoc, I'm sure many people are looking forward to this, especially from countries where em-dashes are used less/none at all.
This will have to be something that is taken up in development of the AsciiDoc language specification, which is now getting underway. See https://projects.eclipse.org/proposals/asciidoc-language