Closed polyglot-jones closed 6 months ago
The only reason I didn't add one so far is because I mostly use scripted automation in my projects, but I agree that to have a basic build system would be a good idea (i.e. just the basic invocation without too many options).
Feel free to create a PR for this.
I've been playing with 2 build specs so far: one that builds HTML using asciidoctor, and one that builds EPUB using asciidoctor-epub3. For some reason, using Ctrl+Shift+B to select the build system aint working for me as advertised. And even if it was, that's too bothersome (i.e. non-deterministic) for me. I'm thinking of defining Ctrl+B+H (i.e. keep Ctrl pressed while typing B then H) to select the HTML builder and run it. Likewise, Ctrl+B+E for EPUB, Ctrl+B+P for PDF, and Ctrl+B+D for DOCX. (Ctrl+B by itself would re-run the same builder as last time, as usual.) Thoughts?
Reminder to self: Expand README install instructions to include the required tool chains: asciidoctor, asciidoctor-epub3, pandoc, etc.
Another Question: Option A: I've been sending the output to the same folder as the ADOC source. (In this case, the .gitignore of your AsciiDoc project needs to specify all the possible output types.) Option B: Another convention is to send it all to ./output. (In this case, the .gitignore of your AsciiDoc project could simply exclude output/*). Option C: ???
For some reason, using Ctrl+Shift+B to select the build system aint working for me as advertised.
Could this be because you've assigned that key-combination for Bold? I remember that one the unmerged PRs assigned CtrlB to make the text/selection bold, and that I mentioned that this would interfere with builds, and that usually bold and italic is achieved by using Alt instead of Ctrl.
Ctrl+Shift+B should bring up the dropdown menu with all the available build choices for a specific file type, that's a default setting so unless you or a package is overriding it globally, it should work that way (and packages shouldn't really alter these settings, it's disruptive).
I'm thinking of defining Ctrl+B+H (i.e. keep Ctrl pressed while typing B then H) to select the HTML builder and run it. Likewise, Ctrl+B+E for EPUB, Ctrl+B+P for PDF, and Ctrl+B+D for DOCX. (Ctrl+B by itself would re-run the same builder as last time, as usual.) Thoughts?
Sounds too intricate. ST remember the last build the user chose from the Builds dropdown menu, on a per-project basis as well as a per file basis. So you really only have to go through the pains of selecting the correct build once, then just keep hitting CtrlB for the same build type.
Also, for more complex build scripts (e.g. multiple builds at once), its always best to just add a build settings file in the ST project folder.
The problem with Asciidoctor is that there are some many backends and possible options that covering even the most common cases is unlikely something that can be achieved via package-specific build systems. Sounds more likely that end users would define their favourite build systems in their User folder, or in their projects directly.
I personally never have used ST builds with Asciidoctor, simply because I heavily rely on CLI options and attributes definitions, that I simply use build scripts or Rakefiles (which is what most Rubysts would use in a medium sized project anyhow).
As oootini pointed out in https://forum.sublimetext.com/t/support-status-for-asciidoc-tor/50492/17, we can add a build system definition to ST3-Asciidoctor. (Being a Windows user, I'll add appropriate content under the "windows" option.)