#317 Extra space inserted with French smartquotes

[Dmitry Shachnev]

Another issue spotted by @jfbu. This command:

echo '(``"entry"``)' | ./tools/rst2xml.py --smart-quotes=yes --language=fr

produces:

<paragraph>(<literal>"entry"</literal> )</paragraph>

Note the extra NBSP (U+00A0) after the </literal>.

Dropping either --language=fr or --smart-quotes=yes makes it disappear.

With the release version (0.13.1), U+202F is inserted instead of U+00A0.

[Günter Milde]

Thanks for the report and analysis.

Fixed in Revision 8061.
Also for some other instances (quotes immediately before inline markup: "foo".

[Dmitry Shachnev]

Thank you!

While trying to pick this to Sphinx I noticed that pyflakes warns about an undefined variable in educate_tokens() function.

The attached one-line patch should fix it.

[Günter Milde]

While the attache patch may fix the pyflakes warning, I don't think it makes smartquotes work as intended. Instead I propose the following:

--- smartquotes.py (Revision 8057)
+++ smartquotes.py (Arbeitskopie)
@@ -514,9 +514,7 @@
do_ellipses = False
do_stupefy = False

• if attr == "0": # Do nothing.
• yield text
• elif attr == "1": # Do everything, turn all options on.

• if attr == "1": # Do everything, turn all options on.
  do_quotes = True
  do_backticks = True
  do_dashes = 1
  @@ -553,13 +551,13 @@

   # skip HTML and/or XML tags as well as emtpy text tokens
   # without updating the last character
  

• if ttype == 'tag' or not text:

• if ttype == 'tag' or attr == "0" or not text:
  yield text
  continue

   # skip literal text (math, literal, raw, ...)
   if ttype == 'literal':
  

• prev_token_last_char = text[-1:]

• prev_token_last_char = text[-1:].replace('"',';').replace("'",';')
  yield text
  continue

[Günter Milde]

Sorry, it should also work with your patch. The simplest change, however, is to turn the first clause into a comment instead of letting it pass.

[David Goodger]

Attached is the output of alltests.py showing a lingering issue with this feature.

[Günter Milde]

Thanks for pointing this out, sorry for the hazzle.
This was actually a regression in [r8062]. Fixed in [r8065].