On 25 January 2011 10:31, Tim Mertens <[email protected]> wrote: > On Jan 24, 2:48 pm, Stuart Rackham <[email protected]> wrote: >> >> This gets round the 'spaces in file paths' problem and would be straight >> forward >> to implement, but would the target syntax relaxation create significant >> regression problems? It would also introduce an insidious line wrapping >> problem >> that would require a change to asciidoc.py e.g. >> >> // This won't work. >> image:file name with >> spaces.png[file >> name with spaces] >> > > I do not personally see what regressions this may cause. Any user who > previously used a space in the path name would result in the image tag > not being rendered correctly in the output, so they would have had to > remove spaces from their paths if they wanted to successfully export > their documentation. I did not notice any problems with images with > or without spaces when I tested this change. It worked in both > instances. > > Also, can you describe the 'line wrapping problem' more fully? I am > not sure I understand the usage case you are describing. Using > '[\S ]' for matching instead of '\S' only adds the single whitespace > character ' ', and not other whitespace characters to the matching > such as \n, \t, \r, etc. So if the concern is matching multiple lines > and/or other whitespace characters besides ' ', I don't think this is > a problem. > > >> Spaces in file paths are a perennial and universal source of bugs and >> irritation, from little things like command-line quoting and mis-cutting and >> pasting file names, right up to large programs. >> >> My rule of thumb is simple *never include spaces in directory or file names* >> or >> sooner or later you will be bitten. >> >> Cheers, Stuart > > Indeed, but unfortunately this is not always possible (as in my case) > and the lack of proper support for it has proved to be quite a pain. > > Thanks, > -Tim
Hi again Tim, As I said in a previous post spaces are not valid characters in URIs so if Stuart added your change to Asciidoc it could produce illegal Docbook and validators later in the toolchain are at liberty to reject it. Not having it in the standard Asciidoc doesn't stop you from continuing to use your modification in a local asciidoc.conf with a toolchain that accepts your output. But a change that could produce illegal output should not be included in the standard Asciidoc distribution. Cheers Lex > > -- > You received this message because you are subscribed to the Google Groups > "asciidoc" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/asciidoc?hl=en. > > -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/asciidoc?hl=en.
