according to the FAQ, non-breaking spaces must be entered as either
entities or attributes.  Are there technical reasons for this?  One of
the advantages of Asciidoc is that documents are readable, and having
either an entity or an attribute instead of a non-breaking space
character hampers readibility.  Provided that the document uses a
suitable encoding (i.e. utf-8), could non-breaking spaces be
recognized as such and handled accordingly?

Although the current asciidoc does its best with non-ascii characters,
it is limited by Python 2, and should really be considered *ascii*doc
as far as the input is concerned.  Long term the Python 3 port will
probably have better unicode support but there is no schedule for its
release.

Even then I am not sure that putting nbsp in the document is a good
idea. It is not visually differentiable from the ascii space so
particular rendering effects would be unexpected, someone editing may
easily replace it with a space and break the output etc.  In general
despite the visual noise I would stick with an explicit marking of
something with special semantics.  You could of course choose your
attribute or replacement (something you didn't mention) to minimise
the visual effect.

Cheers
Lex

I was not aware of this particular FAQ but I have never had any problems
with literal U+000A non-break spaces in my documents.. at least with
html and pdfs generated via a2x.

CJ

Yes, but it isn't guaranteed to work.  The Unicode ability has
improved over the years, but IIUC asciidoc wasn't originally written
unicode aware and it doesn't use Python Unicode strings.  In some
cases ordinary strings will successfully handle Unicode, but in some
cases it won't and thats why Python 3 changed such handling.

Cheers
Lex

I had completely forgotten about it and whatever I did was only briefly
documented in whatever python module was involved... never bothered to
write a patch or anything.. and since I have upgraded to python 2.6,
I have no recollection of what I did at the time, and no way to find
out.. The only thing I remember is that the problem concerned using
non-ASCII literals in python scripts.

Although the problem appears to be similar, I had never thought of this
affecting asciidoc as well, especially since I do not remember having
any issues with non-breaking spaces (or other non-ASCII stuff) in
asciidoc documents.

Perhaps these aspects were addressed or worked around with python 2.6..?

In any case, thank you for your comment.

CJ