-
Notifications
You must be signed in to change notification settings - Fork 188
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
Register this converter for "reveal.js" #253
Comments
To provide context, is the current backend name for the converter "revealjs"? |
Yes 😉 |
Then I agree. |
@mojavelinux What about the attribute So it should produce With the benefit of hindsight, I don't think it's worth it. It will most likely add confusion and it has no real benefit for the end-user. |
It's unclear to me what should happen here. Is the 3.0.0 release an opportunity to improve things or not? |
That's a really good point. That's a strong case for leaving "revealjs" as the official backend name. Though the following would still work:
In the end, this comes down to a usability issue. Do you think people will try to use You can register under multiple names:
As of now, though, the converter can't normalize the backend so that you get consistent value out of it. It might be nice if you could do:
But that doesn't work. So maybe it's best to just stick with a consistent name. If |
So the real question is, should the converter work with a parallel backend alias named |
Doing the The backend test is clearly documented in the README as being I'm going to do some tests. Expect a PR. |
So, with this patch, tests fails: diff --git a/Rakefile b/Rakefile
index 414f5aa..4560ed1 100644
--- a/Rakefile
+++ b/Rakefile
@@ -71,7 +71,7 @@ def build_converter(mode = :pretty)
Asciidoctor::TemplatesCompiler::RevealjsSlim.compile_converter(
templates_dir: TEMPLATES_DIR,
class_name: 'Asciidoctor::Revealjs::Converter',
- register_for: ['revealjs'],
+ register_for: ['revealjs', 'reveal.js'],
backend_info: {
basebackend: 'html',
outfilesuffix: '.html',
diff --git a/examples/multi-destination-content.adoc b/examples/multi-destination-content.adoc
index 1530ed6..b01b945 100644
--- a/examples/multi-destination-content.adoc
+++ b/examples/multi-destination-content.adoc
@@ -49,7 +49,7 @@ Some overview
+-------------------------------------------------+
----
-ifdef::backend-revealjs[=== !]
+ifdef::backend-reveal.js[=== !]
Detailed view
Meaning that registering the backend is not enough for it to change the ifdef backend syntax. So, we are silently going to accept the dotted name for the back-end to reduce surprises if someone use this but we are not going to document it or say it is the preferred form. Existing advanced users keep functionality and we reduce surprises for new users. New users who want advanced ifdef on this backend can search for the documentation if things don't work out of the box. |
I think that's a very fair description of what it should be. Users get an early win by accidentally using |
Yes I think that's a great compromise. On a side note, why does an attribute name cannot contain dots? Is there an usage where it would be confusing for the parser? Spaces should definitely not be allowed. |
Historical reasons. We also kept it reserved just in case we want to do something like: asciidoctor/asciidoctor#528 |
This is resolved now that #297 is merged. |
Since the project name is "reveal.js" I think this converter should be registered for "revealjs" (for backward compatibility) and "reveal.js".
The text was updated successfully, but these errors were encountered: