Wanted to use asciidoc to create current man pages for git, but cannot get asciidoc3 to run.

root@x064:[/home/root]pip3 install asciidoc3
Collecting asciidoc3
  Downloading https://files.pythonhosted.org/packages/be/e9/defb4373cca5e1d42c                                                    d952ee7aeefc1dda0c03d5211c27b6f18e859bea43/asciidoc3-3.1.0.post4.tar.gz (770kB                                                    )
     |################################| 778kB 7.7MB/s
Installing collected packages: asciidoc3
  Running setup.py install for asciidoc3 ... done
Successfully installed asciidoc3-3.1.0.post4
WARNING: You are using pip version 19.2.2, however version 19.2.3 is available                                                    .
You should consider upgrading via the 'pip install --upgrade pip' command.
root@x064:[/home/root]asciidoc
ksh: asciidoc:  not found.
root@x064:[/home/root]asciidoc3
Traceback (most recent call last):
  File "/opt/bin/asciidoc3", line 11, in <module>
    load_entry_point('asciidoc3==3.1.0.post4', 'console_scripts', 'asciidoc3')                                                    ()
  File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 489,                                                     in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2793                                                    , in load_entry_point
    return ep.load()
  File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2411                                                    , in load
    return self.resolve()
  File "/opt/lib/python3.7/site-packages/pkg_resources/__init__.py", line 2417                                                    , in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
ModuleNotFoundError: No module named 'asciidoc3'

This is what seems to have been "installed"

root@x064:[/opt/lib/python3.7]find . | grep asciidoc
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/PKG-INFO
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/SOURCES.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/dependency_links.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/entry_points.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/installed-files.txt
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/not-zip-safe
./site-packages/asciidoc3-3.1.0.post4-py3.7.egg-info/top_level.txt

Can always be user-error, but generally, it just installs. Maybe the .post4 bit is in the way, but I do not know what to correct. Suggestions welcome.

CNAME in gh-pages lists asciidoc.org which clashes with python 2

gh-pages are manual (AFAIK) and need to be updated.

Hello.

Wish I could do this in asciidoc document:

["graphviz", "helloworld.svg", format="svg"]
---------------------------------------------------------------------
digraph helloworld {
hello->world;
}
---------------------------------------------------------------------

and get html and PDF output right, with scalable graphics (no pixels), my primary target being PDF.

I have made a short patch that I'd like to submit to your comments and criticism and perhaps merge.

Regards.

From: Google Group

Ramin Dehghan Posted:

I'm very excited to be introduced to AsciiDoc through the Fedora community as a documentation tool. It really makes life as a "documenter easier".

As a contribution to Fedora and AsciiDoc it would be nice if a moderator would add Fedora Docs in the "Documents written using AsciiDoc" list.

AsciiDoc really does take documentation to a whole new level and the wide range of use by the Fedora community should not be underseen.

Cheers!

>>> from asciidoc3 import asciidoc3api
>>> asciidoc3 = asciidoc3api.AsciiDoc3API()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/insert_username/.virtualenvs/asciidoc3api-venv/lib/python3.7/site-packages/asciidoc3/asciidoc3api.py", line 156, in __init__
    self.__import_asciidoc3()
  File "/home/insert_username/.virtualenvs/asciidoc3api-venv/lib/python3.7/site-packages/asciidoc3/asciidoc3api.py", line 185, in __import_asciidoc3
    self.asciidoc3 = asciidoc3
UnboundLocalError: local variable 'asciidoc3' referenced before assignment

asciidoc3==3.1.0.post5

Example: [red]##r##[green]##g##[blue]##b##

rendered as:

<p>
Example: <span class="red">r</span>[green]g[blue]b
</p>

This one works correctly:

Example: [red]##r## [green]##g## [blue]##b##

Would like to be able to update readme with proper link to Travis for this project and not the py2 version.

Python 3.4 is End of Life: https://devguide.python.org/devcycle/#end-of-life-branches

It looks like the testasciidoc.py program has some undocumented dependencies on GNU source-highlight, GNU LilyPond, and GraphViz. When they are missing, it emits a bunch of error messages and stack traces, but still exits with a successful status.

For example, here's what I get when running against the current code in master, I get output that looks like this. (Full output here.)

$ ./tests/testasciidoc.py --force update &>test-update-out-with-missing-deps.txt
$ echo $?
0

Output:

/bin/sh: source-highlight: command not found
Traceback (most recent call last):
  File "/usr/local/Cellar/asciidoc/8.6.9/etc/asciidoc/filters/graphviz/graphviz2png.py", line 168, in <module>
    app = Application()
  File "/usr/local/Cellar/asciidoc/8.6.9/etc/asciidoc/filters/graphviz/graphviz2png.py", line 68, in __init__
    format_output = subprocess.Popen(["dot", "-T?"], stderr=subprocess.PIPE, stdout=subprocess.PIPE).communicate()[1]
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 710, in __init__
    errread, errwrite)

I think it would be better if it checked for its dependencies, and if they were missing, output a brief error message for each one identifying the missing program. And exited with a non-zero status if any dependencies were missing.

Based on looking into using a setup.py as result of discussion in #44, at this time, I don't believe it's possible without doing a much larger restructuring of asciidoc. While #71 puts down the basics of what's necessary, it still leaves the very unfortunate issue that asciidoc relies on knowing its actual installation location so that it can then load the various conf files and other things. There's no real good way to fix this while also using setup.py that doesn't then require some amount of weird hacking in the path as it gets installed (which is bad). The whole idea of installing it to "any directory" is from an old time and there's no reason to continue to supporting it, especially as moving to a full "pythonic" setup would make it possible to install asciidoc from pypi as well as make it easier for maintainers going forward to build this into package maintainers and the such.

Ideally, I'd say that the best way forward would be to fully embrace setup.py and turn asciidoc into a more "proper" python module such that you'd have an asciidoc folder that contains all python files (as well as __init__.py) which would remove the need for the asciidocapi.py file (as asciidoc would now be normally importable), move the conf/image files inside that folder (and use pkg_resources to load them), and then one could also start to break apart asciidoc.py into smaller module files, add unit testing, etc.

However, this would be a fairly large change and I'd leave it up to @elextr to determine when (if ever) would be an appropriate time that this might be done.

Right now, asciidoc uses optparse (a depreciated module) in two places and getopt in all others. It might be preferable to replace usage of both of these with argparse which would allow for much cleaner and shorter implementation of the command line arguments for the code as opposed to these two older formats.

Moved from closed #41 #41 (comment) #41 (comment) #41 (comment)

As asciidoc-py3 is a consumer of aspell to ensure the quality of its own releases and one would assume that the asciidoc-py3 developers have a strong understanding of the overall asciidoc syntax, it would be nice for the overall asciidoc project to provide a filter for aspell (similar to the existing nroff, TeX, and SGML filters).

This is a note for self to try to solve this issue.
In the lates release (9.0.0 rc2) the test target for make has been switched to the run of testasciidoc.py which causes issues in minimal build environments.

The 1st one is that it doesn't allow to change the CONF_DIR so testasciidoc try to pull the conf file from etc but this is not installed yet. A better solution is required.

Then there are other issues like source-highlight not found and other things like that.
I disabled the run of the tests in Debian for now but it would be nice to have a proper run later, hence this issue opened.

As I did with "Header Syntax" I tried the same with this topic, To make a better understanding of the Document Structure, The problem is: "I don't know to render this ascii into an image".
Thanks
Document_Structure.txt

It'd be nice to have a tagged version of asciidoc with Python 3 support, so distro people could package it. Not sure how early it is to be asking for this, though.

In Fedora, we're going to remove all Python2 packages due of Python2 EOL in 2020.

One of those packages is going to be dblatex, due upstream is quite dead for 2 years and no Python3 port of dblatex is available (at least I am not aware of it).

Do you plan to replace dblatex in asciidoc-py3? Is there any alternative?

With Python 3.7, I see a lot of deprecation warnings here:

https://github.com/asciidoc/asciidoc-py3/blob/986f99d743d0b6ddc2014bdc8dcfa991ab9b4863/asciidoc.py#L471

Right now, the test suite on Travis generates the sources and then confirms that the files it generates matches the file it generates for each step of the test suite. This will only catch things that break asciidoc from generating a particular file, but not regressions, nor is it easy for new developers to catch regressions, as it requires them checking out a prior commit, generating the test suite output, and then going to their new commit and finally testing the suite there.

It'd make sense to actually check in the generated .html files in tests/data/ so that Travis can properly test against them for regressions (as well as then changes to these sources are captured within a given PR as well).

Hi all,
From this commit: 099bca3 the module does not compile with succes

Check this:

root@contrib-stretch:/tmp/asciidoc-master# git checkout 099bca3769c4a83aa459f09ba86f754ba8cbc45a
Previous HEAD position was 4cabf7d... Update CHANGELOG.txt
HEAD is now at 099bca3... Add makefile target for spell checking (#81)
root@contrib-stretch:/tmp/asciidoc-master# autoconf
root@contrib-stretch:/tmp/asciidoc-master# ./configure
checking for a sed that does not truncate output... /bin/sed
checking whether ln -s works... yes
checking for a BSD-compatible install... /usr/bin/install -c
configure: creating ./config.status
config.status: creating Makefile
root@contrib-stretch:/tmp/asciidoc-master# make
Fixing CONF_DIR in asciidoc.py
Fixing CONF_DIR in a2x.py
aspell check -p ./doc/asciidoc.dict doc/a2x.1.txt
make: aspell: Command not found
Makefile:169: recipe for target 'doc/a2x.1.txt' failed
make: *** [doc/a2x.1.txt] Error 127

Congratulations to @MasterOdin (and of course to all the other contributors) on this work! I know what it means to struggle with the asciidoc-code :-)
But there is a drop of bitterness, isn't it? Now we have two (I guess - more or less - 95% terminated) ports, asciidoc-py3 and github.com/asciidoc3/asciidoc3 ...
We should try to merge somehow?

How can I

1. import asciidoc-py3 in a existing python module
2. convert a asciidoc string to html

?? Thank you!

Split this from #44 (comment) to allow me to better track this work, what's left, etc.

Currently, asciidoc "uses" the A-A-P, while is not really supported anymore, not in any distro distribution, python2 only, etc. Ideally, transition away from it to something more universal, like make as nothing that happens here is that unique.

The A-A-P was setup in the following way:

common.aap:

• set global variable to be used in other *.aap scripts for version and release date ($VERS and $DATE) (Added variables to makefile in #54)

main.aap

• vers: prints out the version and release date from common.aap (done in #54)
• vers_update: writes the version variable from common.aap into asciidoc.py, a2x.py, and configure.ac (done in #54)
• tags: delete the tags file and then run ctags over asciidoc.py, asciidocapi.py, tests/testasciidoc.py
• docs: run ./doc/main.aap
• website: run ./examples/website/main.aap
• distribution: runs vers_update, docs, website and then does:
  • Runs autoconf
  • symlinks current directory into asciidoc-$VERS
  • creates a tar (named asciidoc-$VERS.tar.gz) from all files listed in MANIFEST file
  • checks if zip command exists, and if so creates a zip (named asciidoc-$VERS.tar.gz) using the previously created symlink directory
  • Removes the symlink directory
• test: Runs python ./asciidoc.py --doctest, python ./asciidocapi.py, executes ./doc/main.aap test, and then python ./tests/testasciidoc.py run if there are *.html files in ./tests/data

./doc/main.aap:

• all: converts all of the .txt files to the appropriate format (html, man, pdf, epub, etc.) as well as generating out pdf files and the like for distribution
• clean: removes all generated files
• spell: checks the spelling in the text files through aspell using ./doc/asciidoc.dict as a dictionary for it (done in #81)
• clean_testfiles: Removes files generated for tests (uses a subset of what clean does, but does include *.png files)
• test: Runs clean_testfiles and then generates the output from running asciidoc on the files in ./doc

./examples/website/main.aap:

• all: runs asciidoc over the files in the directory, getting html generated files
• copy: deletes and then creates directory ~/webs/asciidoc and then copies the files necessary for the website to that directory. Does execute ./main.aap distribution as part of this to ensure all necessary files have been generated.
• clean: Deletes the generated web pages
• spell: runs aspell over files in directory (done in #81)

The actual installation steps of asciidoc have always been handled by the Makefile.in file.

While one could try and place individual makefiles in the root folder, in docs, in examples/website/ and then do stuff with includes or hierarchal make executes, getting the pathing working correctly (especially if wanting to do a make execute from root into a sub-folder, have to update the $pwd first, then change it back after done execution) and other stuff makes it (to me) not worth trying to maintain 3 different makefiles. My goal is to unify all parts listed above into one topfile Makefile that can be used to build, update, install all parts of asciidoc.

Commands under the the sub-directories (doc and website) will be prefixed with doc_ and website_ respectively. An example of this is doc_spell runs the spell for the doc files and website_spell runs the spell for website files. There may be a top-level command to run both of these (e.g. make spell).

This is to separate the discussion of this from #20, as well as track possible work on this (given that #20 is probably going to be merged before this is done).

asciidoc implements being able to use external filters/code to augment the central asciidoc process. However, it does this by using subprocess.Popen and by setting shell=True. Asciidoc handles putting together the arguments to the program as well as trying to handle properly quoting things. The benefit here is that theoretically, it allows asciidoc to utilize shell builtins (like globing and environment variables).

However, the downside is that it opens itself up to potential attack vectors. An example is this filter tag: [music,slidy-example__1.png" -; rm -rf /tmp/test #] which would ends up getting executed as: '"/usr/local/opt/python/bin/python3.6" "/Users/mpeveler/Github/asciidoc3/filters/music/music2png.py" -m -o "/Users/mpeveler/Github/asciidoc3/doc/slidy-example__1.png" -; rm -rf /tmp/test #" -'

I'm able to get the music filter to pass as one would expect, but attach an attack (rm -rf /tmp/test) to be secondarily executed off the Popen. I'm not sure the ability to use glob or environment variables in these execution statements is worth this security hole, or even trying to do "proper" quoting. In short, just use shell=False and let python handle the quoting of arguments for us.

On the page http://asciidoc.org/publishing-ebooks-with-asciidoc.html Under "Styling your books" there is a link to http://epubzengarden.com/ That website no longer exists at that location.

A number of projects (like docbook) have moved from SF to GH / GL. Need to go through and double check that all existing sourceforge links still point at a project being developed there, and if not, update them to the appropriate place.

Related to #113

It would be helpful for people new to AD to have a statement or paragraph in the Readme or elsewhere that states what asciidoc-py3 is relative to asciidoctor. I'm not looking for a contest, just information on where ad-py3 might be more appropriate and what the project goals are. For example adopting one or more of the highlighted differences? I'm personally aligned with python, but the Dr looks more polished/solid. Add some information to help me choose the best tool for the job. Thanks!

There's a handful of places that remain in source code.

When I read the "Quoted Text" Chapter of "Asciidoc User Guide", I found some ponctuation in the description are not in place (and may be I am wrong), So I tried to rewrite this part to express my Opinion.

Thanks

Quoted_Text.txt

Hi, I was in the master branch to build the code by using the make command, it throwed the following error:

a2x: ERROR: "xmllint" --nonet --noout --valid "/path/to/asciidoc-py3/doc/asciidoc.1.xml" returned non-zero exit status 4

I also tried to run the xmllint command above from my terminal, and the output is:

/path/to/asciidoc-py3/doc/asciidoc.1.xml:5: validity error : Validation failed: no DTD found !
<refentry lang="en">
                   ^

But when I removed the --valid option in the above command, it ran successfully.

P.S. The output of xmllint --version is:

xmllint: using libxml version 20904
   compiled with: Threads Tree Output Push Reader Patterns Writer SAXv1 FTP HTTP DTDValid HTML Legacy C14N Catalog XPath XPointer XInclude Iconv ICU ISO8859X Unicode Regexps Automata Expr Schemas Schematron Modules Debug Zlib Lzma

I am in interested to continuously document my Django project in Asciidoc. However, I did not get a comprehensive tutorial on doing that. Please give me some guideline.

The text just above could be changed to something a bit less experimental like: “The current release of Asciidoc for Python 3 which passes it’s tests and is ready to use in your projects.”

Hello,

are checklists supported? I can't find any reference to them in the AsciiDoc manual, yet third-party howtos say that you can obtain a checklist by using the following format:

= Checklist Test

.List Title
- [x] Checked Item
- [ ] Unchecked Item

The above code does format the list title and the bulleted list, but outputs the [x] and [ ] literally.

I am using the latest version of the master branch and this command:

a2x -f pdf test.asciidoc 

Thanks for your attention.

running a2x with '-b xetex' on mac issues the following warning:

/bin/sh: unwraplatex.py: command not found

and

WARNING: file.adoc: line 3038: filter non-zero exit code: unwraplatex.py: returned 127

asciidoc install does not have unwraplatex.py in the filters directory:

  /opt/local/etc/asciidoc/filters:
  total used in directory 0 available 244.8 GiB
  drwxr-xr-x 39 root wheel 1248 Mar 10 20:28 ..
  drwxr-xr-x  3 root wheel   96 Mar 10 20:28 source
  drwxr-xr-x  7 root wheel  224 Mar 10 20:28 .
  drwxr-xr-x  4 root wheel  128 Mar 10 20:28 music
  drwxr-xr-x  4 root wheel  128 Mar 10 20:28 latex
  drwxr-xr-x  4 root wheel  128 Mar 10 20:28 graphviz
  drwxr-xr-x  4 root wheel  128 Mar 10 20:28 code

adding a copy of unwraplatex.py to my path resolves the error

I don't know if this is really an issue or if I'm doing something wrong.
I'm writing a kanji list and I want to add a different class on each kanji.

So I wrote this :

[testA]#薫# [testB]#病# [testC]#痴# [testD]#痘# [testE]#症# [testF]#疾# +
[testG]#癖# [testH]#匿# [testI]#匠# [testJ]#医# [testK]#匹# [testL]#区# +

But I get that :

<div class="paragraph">
<p>
<span class="testA">薫</span> <span class="testB">病# [testC]#痴</span> <span class="testD">痘</span> <span class="testE">症</span> <span class="testF">疾</span><br />
<span class="testG">癖</span> <span class="testH">匿</span> <span class="testI">匠# [testJ]#医</span> <span class="testK">匹</span> <span class="testL">区</span><br />
</p>
</div>

It seems that something wrong is happening, but only on certain characters (病 and 匠 for this example), I have no idea why.

For reasons which are too tedious to go into, our XML default catalog doesn't have the docbook XML entries in. We need to set SGML_CATALOG_FILES and pass --catalogs to xmllint but as asciidoc wraps xmllint that's harder. I'm currently using this patch as a workaround:

diff --git a/a2x.py b/a2x.py
index 2d7699a..5bb995f 100755
--- a/a2x.py
+++ b/a2x.py
@@ -49,2 +49,4 @@ LYNX = 'lynx'               # alternate text file generator.
 XMLLINT = 'xmllint'         # Set to '' to disable.
+if "SGML_CATALOG_FILES" in os.environ:
+  XMLLINT += " --catalogs"
 EPUBCHECK = 'epubcheck'     # Set to '' to disable.
@@ -636,3 +638,3 @@ class A2X(AttrDict):
         if not self.no_xmllint and XMLLINT:
-            shell('"%s" --nonet --noout --valid "%s"' % (XMLLINT, docbook_file))
+            shell('%s --nonet --noout --valid "%s"' % (XMLLINT, docbook_file))

Processing the following file:

Line 1
// comment
-- Line 2

produces "Line 1" only.
Could you please tell me whether this is a bug or I missed something in User Guide?..

Thank you!

Hi, a Gentoo user reported an issue when compiling a UTF-8 encoded document under a C locale (see https://bugs.gentoo.org/705122). It seems that the issue is that the call to open() in get_source_options() opens the file in text mode without a specific encoding, in which case open() apparently defaults to an encoding that matches the locale. I saw that #5 included a proposed fix for that (by passing an encoding to open()), but that was never merged, and it looks like the changes were not part of the successor PRs. I would think that this would also affect people using other locales that are incompatible with UTF-8.

Attempting to convert the following fragment on its own:

[cols="1,3,3"]
|===
|Language Feature |Markdown |AsciiDoc

|Includes
|_n/a_
a|
[source,text]
----
\include::intro.adoc[]
----
|===

causes the following error:

asciidoc: FAILED: <stdin>: line 2: unexpected error:
asciidoc: ------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 6121, in asciidoc
    has_header = document.parse_header(doctype, backend)
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 1562, in parse_header
    has_header = (Title.isnext() and Title.level == 0 and AttributeList.style() != 'float')
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 2048, in isnext
    lines = reader.read_ahead(2)
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4525, in read_ahead
    while i < count and not self.eof():
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4500, in eof
    return self.read_next() is None
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4504, in read_next
    result = self.read()
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4411, in read
    result = self.read_super()
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4405, in read_super
    result = Reader1.read(self, self.skip)
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4354, in read
    self.open(fname)
  File "/mnt/e/Github/asciidoc-py3/asciidoc.py", line 4244, in open
    self.f = open(fname, 'r', encoding='utf-8')
FileNotFoundError: [Errno 2] No such file or directory: 'intro.adoc'
asciidoc: WARNING: test.asciidoc: line 12: filter non-zero exit code: "/usr/bin/python3" "/mnt/e/Github/asciidoc-py3/asciidoc.py" -b html5  --attribute "source-highlighter=pygments" -a "indir=/mnt/e/Github/asciidoc-benchmarks" -a "blockname=table" -s -: returned 1
asciidoc: WARNING: test.asciidoc: line 12: no output from filter: "/usr/bin/python3" "/mnt/e/Github/asciidoc-py3/asciidoc.py" -b html5  --attribute "source-highlighter=pygments" -a "indir=/mnt/e/Github/asciidoc-benchmarks" -a "blockname=table" -s -

Replacing the \include here with something else works as expected in that the text is surrounded by a source highlighter box.

The output of asciidoc-py right now:

Expected output from asciidoctor:

From my understanding, the \include here should be escaped (https://asciidoc.org/userguide.html#_system_macros) as it has a leading \, but it's not, causing the include to be interpreted literally, and so then throws the error about not being able to load intro.adoc. Doing \include::intro.adoc[] on its own does work as expected and then just prints the text literal and does not attempt to actual include the file.

Here is the usage screen for tests/testasciidoc.py:

./tests/testasciidoc.py --help                                                                                                                           [21:43:54]
illegal command options

Usage: testasciidoc.py [OPTIONS] COMMAND

Run AsciiDoc conformance tests specified in configuration FILE.

Commands:
  list                          List tests
  run [NUMBER] [BACKEND]        Execute tests
  update [NUMBER] [BACKEND]     Regenerate and update test data

Options:
  -f, --conf-file=CONF_FILE
        Use configuration file CONF_FILE (default configuration file is
        testasciidoc.conf in testasciidoc.py directory)
  --force
        Update all test data overwriting existing data

Based on this, I would expect that usage would be that I can specify a test number as well as a backend for that number. It's not obvious that you can pass an integer (for NUMBER) or a string (for BACKEND) or both and the order doesn't matter. These are loosely positional arguments, but is not obvious in how that is, unless you look at the arg parsing code.

Would it make sense to change it to be that testasciidoc.py update|run [--number NUMBER] [--backend BACKEND]. This allows a more straightforward usage model (that can be explained concisely in a usage string). Can make it so the flags are either --number or -n, and --backend or -b.

The decode method on string objects doesn't exist in Python 3.6 (https://docs.python.org/3/library/stdtypes.html#str.encode). Line 263 in particular is an offender. There may be other uses but I haven't looked. I was able to trigger it by using xhtml as the output format.

like “tracking ID”，can I use with asciidoc?

I use a2x to generate a man page from an asciidoc text file. In asciidoc-8.6.8, the --destination-dir option of a2x was documented as "Output directory." and it worked as documented. With asciidoc-8.6.9, the documentation says that the option "is only applicable to HTML based output formats". The option continues to work with 8.6.9 as before, but a warning is printed: "a2x: WARNING: --destination-dir option is only applicable to HTML based outputs"

Lex Trotman says there is no such limitation in the current code and the warning message is wrong:
https://groups.google.com/forum/#!topic/asciidoc/5ByGKFq1fMs

Hello! I was taking a look at this project (specifically @MasterOdin 's fork/Pull Request #2 since it seems there's going to be incoming changes) as I, and many others, are interested in the state of Asciidoc for Python 3. One thing I noticed is some rather inconsistent spacing between classes/functions and other PEP 8-related formatting quirks.

I would be happy to go through and make all of those tedious adjustments and send a PR, but I wanted to check that it's something that may be wanted before I get neck deep in the code doing so (or in case I missed some intentional reasoning such as compact source code).

If this is not desired, feel free to close this issue!

Watching the discussion going on in https://groups.google.com/forum/#!topic/asciidoc/GAk4b_VUmHc, one of the posters repeatedly said that the python implementation is not actively maintained or developed. Given that no one tried to say otherwise, it makes me wonder where the maintainer(s) (just @elextr these days?) of the asciidoc python implementation would like to take this project, or their vision of its future. Is this project truly considered dead and should the README just indicate that and point everyone to asciidoctor and these repos/organization archived? Should anyone interested in actually working on a python implementation just make a fork of the project and work on that (a la asciidoc3)? Just keep making PRs to throw into the void to hopefully see a python3 version formally released?

For my part, I would contribute more to this project, but I'm greatly discouraged on spending time on this when I see some of my PRs languish for upwards of 6 months with zero motion. I realize that time is not free for anyone, nor are maintainers required to devote their lives to the project, and I would just like to establish some sort of concrete idea of direction and it really is not clear to me.

To clarify the syntax of header I made this example and I want your opinion.
Thanks
Header'Syntax.txt

When trying to specify custom css file, style is just partially applied:
CMD: python asciidoc.py -a stylesheet=my_styles/my_style.css doc/asciidoc.txt
after adding the path to stylesheets directory WARNING is displayed and no output is generated:
CMD: python asciidoc.py -a stylesheet=my_styles/my_style.css -a stylesdir=my_styles doc/asciidoc.txt
WARNING: include file not found: {working_dir}\my_styles\asciidoc.css

Problem could be solved if I rename my_style.css to asciidoc.css and adding both arguments stylesheet and stylesdir when calling asciidoc.py from CLI.

Would you be interested in a Mac Homebrew formula for asciidoc-py3 so it could be easily installed on macOS? Might make it easier to get people to test it.

The current Mac Homebrew asciidoc formula points to the Python2 implementation. Setting up a parallel formula could make migration to the Python3 version easier, assuming the port is successful.

if its only a single file that specifies installation then it probably isn't a problem.

It would be a single file (and maybe a README to go with it), but it needs to be maintained in a separate repo that functions as a Homebrew "tap". This is their mechanism for supporting third-party formula definitions.

I've set up an example of how this could be done in my apjanke/personal tap here: https://github.com/apjanke/homebrew-personal/blob/70f8de6ab173170bc0e6088ba99599fb36001e1a/Formula/asciidoc-py3.rb. Once there are tagged releases of the py3 port, one could be added as the "devel" version, in addition to the "head" definition.

And then is it possible to have the Python 2 entry advise using the -py3 version after its made available?

The asciidoc-py3 project looks a little young to be listed in core Homebrew yet. But you could set up this "custom" asciidoc-py3 formula for use during the port/migration, and if the migration to py3 is successful, the main Homebrew asciidoc formula could be changed to use the new py3 version, which would migrate all the existing users over when they did a brew upgrade. Then the custom formula could then go away, unless you wanted to keep it around for testing pre-release versions.

(Discussion migrated from #40 (comment))

Asciidoc includes a number of Javascripts from other projects (ASCIIMathML.js for example). If anyone uses them it might be worthwhile comparing those to the upstream project to see if a newer version is useful (and compatible).