[Docutils-develop] [docutils:bugs] #307 Non-breaking whitespace and the inline markup recognition rules.

[Edward d'Auvergne]

---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Wed Feb 08, 2017 08:40 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Edward d'Auvergne]

Here is an easy way to reproduce, with normal spaces:

```
$ python3 -c "print(u'A | B')" | rst2xml > /dev/null
$
```

And with non-breaking whitespaces:

```
$ python3 -c "print(u'A | B')" | rst2xml > /dev/null
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
$
```



---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Wed Feb 08, 2017 08:40 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Edward d'Auvergne]

Let me try again without the SF web interface normaling all whitespace:

```
$ python3 -c "print(u'A\u00a0|\u00a0B')" | rst2xml > /dev/null
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
$
```


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Wed Feb 08, 2017 08:46 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Edward d'Auvergne]

This bug appears to affect the whole Unicode Zs block (Separator, Space), which is defined as 'whitespace'. For example:

```
$ python3 -c "print(u'A\u200a|\u200aB')" | rst2xml > /dev/null
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

And:

```
$ python3 -c "print(u'A\u2000|\u2000B')" | rst2xml > /dev/null
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

But even if the 'whitespace' text in the rST specification is interpreted as not including the Unicode Zs whitespace block, the NBSP character should be as it is ASCII character 255 and is clearly whitespace.


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Wed Feb 08, 2017 08:48 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Günter Milde]

The behaviour is intended (this way, NBSP can be used as an "ivisible variant" of the escaped space (with some side-effects, of course)).

The specification may need improving. As we already pointed out, it is to be read with the Docutils source as background/context info to solve ambiguities.

In states.py, the regular expressions for inline markup recognition use [ \n] (i.e. the set of
SPACE and NEWLINE) as whitespace.

BTW: NBSP is no ASCII character (ASCII is 7bit)

The implementation also excludes TAB, however, TABs are converted to SPACEs before the parsing, so an explainging footnote might say:
Whitespace¹

¹ space, tab, and newline.


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Thu Feb 09, 2017 10:15 AM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[David Goodger]

+1 on "Whitespace¹ // ¹ space, tab, and newline."


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Thu Feb 09, 2017 01:19 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Edward d'Auvergne]

Restricting to space, tab, and newline sounds good. But should `\r` be listed too? Consideration of Unicode Zs might be of interest in the future - especially since typing in any non-European character set will almost always result in 'special' Zs spaces - but then you'd have to exclude NBSP.

For the NBSP in ASCII, I had that mixed up. It's the very last character in the extended ASCII set (8-bit).


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Thu Feb 09, 2017 07:57 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Günter Milde]

Sorry, I overlooked the recent change "Recognize non-ASCII whitespace around inline literal, target and substitution." https://sourceforge.net/p/docutils/code/8003/

This means it should be no difference between SPACE, NBSP, EM-SPACE etc. if used *outside* inline markup.
OTOH, *inside* inline markup, NBSP is allowed, e.g., ``A * emphas * es.`` (with NBSP inside the `*`) is valid emphasized text (as is ``A * emphas * es.`` with an EM SPACE before the closing markup).

Not sure, whether we should change the spec or the implementation, though. May be best to discuss this on docutils-devel.


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Thu Feb 09, 2017 08:20 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Günter Milde]

Is there a use case to allow NBSP (or other non-ASCII whitespace) inside inline markup strings?

If not, I propose the attached patch to bring the implementation in line with the spec.
(Of course, whitespace stays allowed inside inline markup, but not bordering the markup strings.)


Attachments:

- [no-whitespace-inside-inline-markup.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/1bbe9c0d/a301/attachment/no-whitespace-inside-inline-markup.patch) (6.7 kB; text/html)


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Thu Feb 09, 2017 09:59 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[David Goodger]

By "inside" I believe you mean "immediately inside" and immediately adjacent to the markup characters.

I'm troubled by the presence of a specific test that exercises this feature. This was added in r7232, by you, GÃŒnter. Can you speak to why this test was added, and why it's now OK to remove it?


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Sat Feb 11, 2017 05:12 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Günter Milde]

Post by David Goodger
By "inside" I believe you mean "immediately inside" and immediately adjacent to the markup characters.

Yes. The idea is to have a common interpretation of the term "whitespace" in the inline markup recognition rules (http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules).

Since 2011 (release 7232), all sorts of whitespace count in rules 7 and 8
(r8003 is a catchup as r7232 did miss inline literal, target and substitution markup).
Up to now, only NL and SPACE count in rules 1 and 2.

The proposed patch changes the interpretation of the term "non-whitespace"
in inline markup recognition rules 1 and 2 to be in line with the interpretation of
"whitespace" in rules 7 and 8.

Post by David Goodger
I'm troubled by the presence of a specific test that exercises this feature. This was added in r7232, by you, GÃŒnter. Can you speak to why this test was added...

r7232 "Allow also non-ASCII whitespace characters around inline markup."
changed behaviour regarding rules 7 and 8, but left rules 1 and 2 untouched.
It is one of many steps to get aproper solution for bug [ 3402314 ]
"Strict rules for role-surrounding chars are america-centric" (now [173]).

The troubeling change to the existing test case,

-\u00bf*punctuation*? \u00a1*examples*!\u00a0*too*.
+\u00bf*punctuation*? \u00a1*examples*!\u00a0*\u00a0no-break-space\u00a0*.

was just cosmetics (both, the old and new sample string are not affected by the code changes in r7232) done to make explicit in the sample string that \u00a0 is not punctuation but the NBSP character.

Post by David Goodger
and why it's now OK to remove it?

Using a literal NBSP also on the "inside" of the markup was an unwise and unneeded decision. It works because of the current narrow interpretation of "whitespace" in rules 1 and 2 but was not intended to fix this behaviour.

OTOH, the patch makes the inline markup recognition rules simpler and more consistent:

+1 "non-whitespace" = "Unicode characters" \ "whitespace"

+1 " * " is valid for any type of whitespace character.

-0 "* text *" is no longer emphasized if NBSP is used between * and "text".

-> Is ther a use case for "` spam`:spam:" or "| subs|" or similar cases of
whitespace at the egdes of inline elements?


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Sat Feb 11, 2017 05:12 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[David Goodger]

Post by David Goodger
and why it's now OK to remove it?
Using a literal NBSP also on the "inside" of the markup was an unwise and unneeded decision. It works because of the current narrow interpretation of "whitespace" in rules 1 and 2 but was not intended to fix this behaviour.
-> Is ther a use case for "spam:spam:" or "| subs|" or similar cases of
whitespace at the egdes of inline elements?

No. As long as it can be backslash-escaped, all whitespace should be treated equally.


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** open
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Sat Feb 11, 2017 05:12 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Guenter Milde]

Post by David Goodger

Post by Günter Milde
Using a literal NBSP also on the "inside" of the markup was an unwise
and unneeded decision. It works because of the current narrow
interpretation of "whitespace" in rules 1 and 2 but was not intended
to fix this behaviour.
-> Is ther a use case for "spam:spam:" or "| subs|" or similar cases of
whitespace at the egdes of inline elements?

No. As long as it can be backslash-escaped, all whitespace should be treated equally.

Agreed.

OK for the patch then?

This would be for 0.14 or 1.0 then (behaviour change with possible breaks
to inline markup in rare cases).

Postpone after the "not urgent 0.13.2" or skip 0.13.2?

Günter


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Plea

[David Goodger]

Post by Guenter Milde

Post by David Goodger

Post by Günter Milde
Using a literal NBSP also on the "inside" of the markup was an unwise
and unneeded decision. It works because of the current narrow
interpretation of "whitespace" in rules 1 and 2 but was not intended
to fix this behaviour.
-> Is ther a use case for "spam:spam:" or "| subs|" or similar cases of
whitespace at the egdes of inline elements?

No. As long as it can be backslash-escaped, all whitespace should be treated equally.

Agreed.
OK for the patch then?

Yes.

Post by Guenter Milde
This would be for 0.14 or 1.0 then (behaviour change with possible breaks
to inline markup in rare cases).
Postpone after the "not urgent 0.13.2" or skip 0.13.2?

I think we can skip 0.13.2, and release 0.14 or 1.0 (I don't care
either way). Whichever we choose, we should drop support for Python
2.4 (released November 30, 2004; >12 years ago!).

And the feature release after that should drop 2.5 (September 16,
2006) support as well. Even 2.6 (October 1, 2008) and 2.7 (July 3,
2010) support should be dropped eventually, as 2.7 has a planned end
of life in 2020 (https://www.python.org/dev/peps/pep-0373/).

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply to the list.

[Guenter Milde]

Post by David Goodger
I think we can skip 0.13.2, and release 0.14 or 1.0 (I don't care
either way). Whichever we choose, we should drop support for Python
2.4 (released November 30, 2004; >12 years ago!).
And the feature release after that should drop 2.5 (September 16,
2006) support as well.

The REALEASE-NOTES currently say:

Release 1.0
-----------

* remove the `handle_io_errors` option from io.FileInput/Output.
Used by Sphinx up to version 1.3.1, fixed in 1.3.2 (Nov 29, 2015).

* Drop support for python 2.4.

I suggest to

* call the next release 0.14
(including the whitespace fix and the latex classes fix)
@Engelbert, could comment on the latex classes fix, please?

in 0.14, announce for 1.0

- * Drop support for python 2.4.
+ * Drop support for python 2.4 and 2.5.

* Sort out the open issues and remove pre 2.6 compatibility code before
releasing 1.0.

Post by David Goodger
Even 2.6 (October 1, 2008) and 2.7 (July 3,
2010) support should be dropped eventually, as 2.7 has a planned end
of life in 2020 (https://www.python.org/dev/peps/pep-0373/).

I have no clear opinion on when to remove 2.6 support but propose to support
2.7 until its planned end in 2020 (or at least until the Debian stable
release uses 3.x as default python version).

Günter


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "R

[David Goodger]

Post by Guenter Milde

Post by David Goodger
I think we can skip 0.13.2, and release 0.14 or 1.0 (I don't care
either way). Whichever we choose, we should drop support for Python
2.4 (released November 30, 2004; >12 years ago!).
And the feature release after that should drop 2.5 (September 16,
2006) support as well.

Release 1.0
-----------
* remove the `handle_io_errors` option from io.FileInput/Output.
Used by Sphinx up to version 1.3.1, fixed in 1.3.2 (Nov 29, 2015).
* Drop support for python 2.4.
I suggest to
* call the next release 0.14
(including the whitespace fix and the latex classes fix)
@Engelbert, could comment on the latex classes fix, please?

OK, but:

* Drop support for Python 2.4 in Docutils 0.14.

It was clearly the intention to drop Python 2.4 support in *the next
release*, whatever we call it. And I'm going to commit some code that
relies on Python 2.5 functionality shortly (_html_base.patch attached
to "[Docutils-develop] `context` stack (was: 1.0.0 & API)" on Feb 14;
last warning!).

Post by Guenter Milde
in 0.14, announce for 1.0
- * Drop support for python 2.4.
+ * Drop support for python 2.4 and 2.5.

We should just "announce for next release: Drop support for Python 2.5."

Don't specify a number. This way, we'll have flexibility. If we list
1.0 again, we'll look foolish again if we deliver 0.15 instead.

Post by Guenter Milde
* Sort out the open issues and remove pre 2.6 compatibility code before
releasing 1.0.

.replace('1.0', 'the next version), same reason.

Post by Guenter Milde

Post by David Goodger
Even 2.6 (October 1, 2008) and 2.7 (July 3,
2010) support should be dropped eventually, as 2.7 has a planned end
of life in 2020 (https://www.python.org/dev/peps/pep-0373/).

I have no clear opinion on when to remove 2.6 support but propose to support
2.7 until its planned end in 2020 (or at least until the Debian stable
release uses 3.x as default python version).

Fine with me, for now. What if Debian continues to ship Python 2.7.x
as the default well past the end of life date (2020 or whatever it
becomes)?

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply to the list.

[Dmitry Shachnev]

Post by Guenter Milde
I have no clear opinion on when to remove 2.6 support but propose to support
2.7 until its planned end in 2020 (or at least until the Debian stable
release uses 3.x as default python version).

In Debian there is no such thing as default Python version.

We have the default Python 2.x version (2.7 atm) and the default Python 3.x
version (3.5 atm).

Our Python Policy says that Python 3 is highly preferred [1].

If you mean the target of /usr/bin/python symlink, then it currently points
to python2.7, and will likely never point to anything else. When Python 2.7
is dropped, that symlink will be dropped too.

[1]: https://www.debian.org/doc/packaging-manuals/python-policy/ch-python3.html

--
Dmitry Shachnev

[Günter Milde]

- **status**: open --> closed-fixed
- **Comment**:

Fixed in [r8038]. Regular expressions for inline markup parsing now use the special sequence `\s`, this will match the characters [ \t\n\r\f\v] plus whatever is classified as space in the Unicode character properties database.

Mark, that 200B ZERO WIDTH SPACE (commonly abbreviated ZWSP) is not a whitespace character according to Unicode 9.0.0 (character class Cf, not Zs) and hence not regarded as whitespace.



---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** closed-fixed
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Sat Feb 11, 2017 05:12 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Edward d'Auvergne]

That'll be the [Zs Unicode category](http://www.fileformat.info/info/unicode/category/Zs/list.htm). And yes, ZWSP is not used for adding spaces, but is very important for the [Unicode line breaking algorithm (UAX #14)](http://unicode.org/reports/tr14/). Thank you for cleaning this up! If you'd like some suggestions for clarifying "whitespace" in the spec, as a diff, just say. Though this should be rather simple.


---

** [bugs:#307] Non-breaking whitespace and the inline markup recognition rules.**

**Status:** closed-fixed
**Group:** Default
**Created:** Wed Feb 08, 2017 08:40 PM UTC by Edward d'Auvergne
**Last Updated:** Thu Feb 16, 2017 08:35 PM UTC
**Owner:** nobody


The rST text `A | B` is treated fine, but if the two spaces are replaced by non-breaking whitespace, eg `A | B`, then the following warning is given:

```
<stdin>:1: (WARNING/2) Inline substitution_reference start-string without end-string.
```

According to the [inline markup recognition rules](http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#inline-markup-recognition-rules), both should not require escaping.


---

Sent from sourceforge.net because docutils-***@lists.sourceforge.net is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.