docutils-develop — For developer discussions of the implementation.

[Docutils-develop] [docutils:bugs] #474 IndexError while parsing specially crafted option arguments

[Günter M. <mi...@us...>]

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

The underlying problem (splitting the "option marker" inside < >) is fixed in [r9473].
This also solves the `IndexError`.
Thank you for reporting.



---

**[bugs:#474] IndexError while parsing specially crafted option arguments**

**Status:** open-fixed
**Created:** Tue Sep 12, 2023 07:05 PM UTC by Andrew Pan
**Last Updated:** Tue Sep 12, 2023 07:13 PM UTC
**Owner:** nobody
**Attachments:**

- [reproducer.py](https://sourceforge.net/p/docutils/bugs/474/attachment/reproducer.py) (88 Bytes; text/x-python-script)


When rendering arbitrary input with the RST parser, I expect docutils to either return successfully or raise a `MarkupError`. However, the following input causes docutils to raise an `IndexError`:

`-a<, , >`

docutils tries to render this as an option group. It splits the group into individual options:

<small>docutils/parsers/rst/states.py:1555:</small>
```python
optionstrings = match.group().rstrip().split(', ')
```

Which yields the following array (note the empty string):

```
(Pdb) optionstrings
['-a<', '', ' >']
```

Which is then tokenized with `split()`. When processing an empty "option", `split()` yields an empty array, causing this statement to raise an `IndexError`:


<small>docutils/parsers/rst/states.py:1559:</small>
```python
firstopt = tokens[0].split('=', 1)
```


I checked [the documentation](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#option-lists) and it appears that angle brackets are usually used to denote option arguments. I'm not sure if docutils should parse and render this kind of input. If it shouldn't, it would be nice to get a `MarkupError`.

Here's the output from `docutils -V`:
`docutils (Docutils 0.20.1, Python 3.11.3, on darwin)`

I've reproduced this on macOS `13.5.2 (22G91)` and Ubuntu 22.04 with the attached reproducer.


---

Sent from sourceforge.net because doc...@li... 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.

[Docutils-develop] [docutils:bugs] #477 Generated man page leads to groff warning "TE macro called with TW register undefined"

[engelbert g. <gr...@us...>]

the title is misleading and the solution looks like something was dropped on the keyboard

on my system "man 7 man" says
~~~
   Title line
       The  first command in a man page (after comment lines, that is, lines that start
       with .\") should be

              .TH title section date source manual
~~~
I had to move a lot of lines before .TH because indexers had problems
and I will add this droplet too, BUT please is there anyone considering
the fact that a manual-system should be less cryptic

and the page might be in need of a cleanup, it also says
~~~
       Many  man pages begin with '\" followed by a space and a list of characters, indicating how the page is to be preprocessed.  For  portability’s  sake  to  non-troff  translators we recommend that you avoid using anything other than tbl(1),
       and Linux can detect that automatically.
~~~
then the fact that the apostrophe and the dot are the same comes up at sometime ...

i guess carnival season never ended for centuries.



---

**[bugs:#477] Generated man page leads to groff warning "TE macro called with TW register undefined"**

**Status:** open
**Labels:** manpage writer 
**Created:** Sun Nov 12, 2023 06:15 PM UTC by Dmitry Shachnev
**Last Updated:** Sun Nov 12, 2023 09:02 PM UTC
**Owner:** engelbert gruber


In Debian, we have a `lintian` tool which runs various checks on the built packages. Among other things, it makes sure that man pages explicitly require all preprocessors that they need.

I have received a [bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053355) about an error reported by that tool. It looks like that if a document contains a table, `rst2man` generates macros `.TS` and `.TE` which are recognized by [tbl](https://manpages.debian.org/testing/groff-base/tbl.1.en.html) preprocessor, but does not generate a dependency on it.

Here is a minimal reproducing example:
```
$ cat table.rst
.. list-table::

   * - Foo
     - Bar
$ rst2man table.rst | MANROFFSEQ='' man -l -Z - >/dev/null
an.tmac:<standard input>:43: warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined)
```

According to [this email](https://lists.debian.org/debian-devel/2023/08/msg00220.html), to fix this error, `rst2man` should add this line on top of the generated man page:

    '\" t

Cc @branden — I think you are interested in all manpage-related issues.


---

Sent from sourceforge.net because doc...@li... 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.

Re: [Docutils-develop] [docutils:bugs] #477 Generated man page leads to groff warning "TE macro called with TW register undefined"

[G. B. R. <g.b...@gm...>]

Hi Dmitry,

Thanks for looping me in.

At 2023-11-12T18:15:10-0000, Dmitry Shachnev via Docutils-develop wrote:
> Here is a minimal reproducing example:
> ```
> $ cat table.rst
> .. list-table::
> 
>    * - Foo
>      - Bar
> $ rst2man table.rst | MANROFFSEQ='' man -l -Z - >/dev/null
> an.tmac:<standard input>:43: warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined)
> ```
> 
> According to [this email](https://lists.debian.org/debian-devel/2023/08/msg00220.html), to fix this error, `rst2man` should add this line on top of the generated man page:
> 
>     '\" t
> 
> Cc @branden — I think you are interested in all manpage-related issues.

Yes, that is correct.  If you know you are going to be generating a
tbl(1) table, then including

    '\" t

at the beginning of the generated man page is important.  It tells the
man(1) program to run tbl(1) and ensures that the table will be properly
formatted.

You _could_ just include the `'\" t` unconditionally, since tbl(1) will
not do any damage to a well-formed man page that doesn't use tables, and
the time tbl(1) takes to run has not been noticeable for decades.

I would do whichever is easier.

Regards,
Branden

[Docutils-develop] [docutils:bugs] #477 Generated man page leads to groff warning "TE macro called with TW register undefined"

[engelbert g. <gr...@us...>]

- **labels**:  --> manpage writer
- **assigned_to**: engelbert gruber



---

**[bugs:#477] Generated man page leads to groff warning "TE macro called with TW register undefined"**

**Status:** open
**Labels:** manpage writer 
**Created:** Sun Nov 12, 2023 06:15 PM UTC by Dmitry Shachnev
**Last Updated:** Sun Nov 12, 2023 06:15 PM UTC
**Owner:** engelbert gruber


In Debian, we have a `lintian` tool which runs various checks on the built packages. Among other things, it makes sure that man pages explicitly require all preprocessors that they need.

I have received a [bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053355) about an error reported by that tool. It looks like that if a document contains a table, `rst2man` generates macros `.TS` and `.TE` which are recognized by [tbl](https://manpages.debian.org/testing/groff-base/tbl.1.en.html) preprocessor, but does not generate a dependency on it.

Here is a minimal reproducing example:
```
$ cat table.rst
.. list-table::

   * - Foo
     - Bar
$ rst2man table.rst | MANROFFSEQ='' man -l -Z - >/dev/null
an.tmac:<standard input>:43: warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined)
```

According to [this email](https://lists.debian.org/debian-devel/2023/08/msg00220.html), to fix this error, `rst2man` should add this line on top of the generated man page:

    '\" t

Cc @branden — I think you are interested in all manpage-related issues.


---

Sent from sourceforge.net because doc...@li... 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.

[Docutils-develop] [docutils:bugs] #477 Generated man page leads to groff warning "TE macro called with TW register undefined"

[Dmitry S. <man...@us...>]

---

**[bugs:#477] Generated man page leads to groff warning "TE macro called with TW register undefined"**

**Status:** open
**Created:** Sun Nov 12, 2023 06:15 PM UTC by Dmitry Shachnev
**Last Updated:** Sun Nov 12, 2023 06:15 PM UTC
**Owner:** nobody


In Debian, we have a `lintian` tool which runs various checks on the built packages. Among other things, it makes sure that man pages explicitly require all preprocessors that they need.

I have received a [bug](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053355) about an error reported by that tool. It looks like that if a document contains a table, `rst2man` generates macros `.TS` and `.TE` which are recognized by [tbl](https://manpages.debian.org/testing/groff-base/tbl.1.en.html) preprocessor, but does not generate a dependency on it.

Here is a minimal reproducing example:
```
$ cat table.rst
.. list-table::

   * - Foo
     - Bar
$ rst2man table.rst | MANROFFSEQ='' man -l -Z - >/dev/null
an.tmac:<standard input>:43: warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined)
```

According to [this email](https://lists.debian.org/debian-devel/2023/08/msg00220.html), to fix this error, `rst2man` should add this line on top of the generated man page:

    '\" t

Cc @branden — I think you are interested in all manpage-related issues.


---

Sent from sourceforge.net because doc...@li... 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.

[Docutils-develop] [docutils:bugs] #473 Pip installs an incompatible version (20.1) for Python 2

[Günter M. <mi...@us...>]

Here, `pip download docutils -vv` reports (amongst a lot of other things)
~~~
 Found link [...]docutils-0.20.1.tar.gz[...] (from https://pypi.org/simple/docutils/) (requires-python:>=3.7), version: 0.20.1
 ~~~
 so pip should know that `docutils-0.20.1.tar.gz` does not work with 2.7!

This seems to be a problem with pip2.


---

**[bugs:#473] Pip installs an incompatible version (20.1) for Python 2**

**Status:** open
**Created:** Thu Aug 31, 2023 10:29 AM UTC by Richard Fennessy
**Last Updated:** Thu Aug 31, 2023 01:11 PM UTC
**Owner:** nobody


Hi,

Recently, we've noticed that running the command `pip install docutils` on an old host with only Python 2 installed has begun to install an incompatible version, `20.1`. (First noticed when the incompatibility broke `awscli`).

The output of `pip install docutils -vvv` shows that previous versions are correctly rejected, but  `20.1` is accepted for some reason:

(truncated for clarity)
~~~
    Found link https://files.pythonhosted.org/packages/57/b1/b880503681ea1b64df05106fc7e3c4e3801736cf63deffc6fa7fc5404cf5/docutils-0.18.1.tar.gz#sha256=679987caf361a7539d76e584cbeddc311e3aee937877c87346f31debc63e9d06 (from https://pypi.org/simple/docutils/), version: 0.18.1
    Found link https://files.pythonhosted.org/packages/ac/f7/aec2c4e0acabe771b207ff2b480f2bc1adaef02771ff12f9561e66df33cf/docutils-0.19b1-py2.py3-none-any.whl#sha256=bf87502630148119873347981a8efc2438e6f254f995b7699501f0e4aa538915 (from https://pypi.org/simple/docutils/), version: 0.19b1
    Found link https://files.pythonhosted.org/packages/cf/65/85a3da30f9a256a29b9cf947d603848eb6a4339900df73fbd56551c8b844/docutils-0.19b1.tar.gz#sha256=79b3ab5228b154ecaf4cbf08a1d8c213e3a127826193bafb5a035d0a7a88af0c (from https://pypi.org/simple/docutils/), version: 0.19b1
    Skipping link https://files.pythonhosted.org/packages/93/69/e391bd51bc08ed9141ecd899a0ddb61ab6465309f1eb470905c0c8868081/docutils-0.19-py3-none-any.whl#sha256=5e1de4d849fee02c63b040a4a3fd567f4ab104defd8a5511fbbc24a8a017efbc (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/6b/5c/330ea8d383eb2ce973df34d1239b3b21e91cd8c865d21ff82902d952f91f/docutils-0.19.tar.gz#sha256=33995a6753c30b7f577febfc2c50411fec6aac7f7ffeb7c4cfe5991072dcf9e6 (from https://pypi.org/simple/docutils/), version: 0.19
    Skipping link https://files.pythonhosted.org/packages/73/f1/455c0f5f29e853956947745299e65c494fe7ed49bce41fd05a738d931da3/docutils-0.20rc1-py3-none-any.whl#sha256=f9cd313159e9611199127c59b63c4890e808cb8cb6c2fe5f9a271cfd6df32676 (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/1d/0e/f03180dcf1e0727083dc5a303f15cacaf7ae1686f0a4efc295f5ff938197/docutils-0.20rc1.tar.gz#sha256=1077d5e5a529972f340550a99f55c59420095e40eb0eef0824083557a6589e98 (from https://pypi.org/simple/docutils/), version: 0.20rc1
    Skipping link https://files.pythonhosted.org/packages/41/3b/11740ed0f36e408ff3d5bd259af0c3330d899c17562f9964b7fbc90756f9/docutils-0.20-py3-none-any.whl#sha256=a428f10de4de4774389734c986a01b4af2d802d26717108b0f1b9356862937c5 (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/e6/a9/8ddfaa7a9414e42520e0041d1354ebda699e4eb1b47e2f1b6d8bda66aba6/docutils-0.20.tar.gz#sha256=f75a5a52fbcacd81b47e42888ad2b380748aaccfb3f13af0fe69deb759f01eb6 (from https://pypi.org/simple/docutils/), version: 0.20
    Skipping link https://files.pythonhosted.org/packages/26/87/f238c0670b94533ac0353a4e2a1a771a0cc73277b88bff23d3ae35a256c1/docutils-0.20.1-py3-none-any.whl#sha256=96f387a2c5562db4476f09f13bbab2192e764cac08ebbf3a34a95d9b1e4a59d6 (from https://pypi.org/simple/docutils/); it is not compatible with this Python
    Found link https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz#sha256=f08a4e276c3a1583a86dce3e34aba3fe04d02bba2dd51ed16106244e8a923e3b (from https://pypi.org/simple/docutils/), version: 0.20.1
  Using version 0.20.1 (newest of versions: 0.3, 0.3.5, 0.3.7, 0.3.9, 0.4, 0.5, 0.6, 0.7, 0.8, 0.8.1, 0.9, 0.9.1, 0.10, 0.11, 0.12, 0.13.1, 0.14, 0.15, 0.15.post1, 0.15.1, 0.15.1.post1, 0.15.2, 0.16, 0.17, 0.17.1, 0.18, 0.18.1, 0.19, 0.20, 0.20.1)
  Looking up "https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz" in the cache
  Current age based on date: 759150
  Freshness lifetime from max-age: 365000000
  The response is "fresh", returning cached response
  365000000 > 759150
  Using cached https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz
  Downloading from URL https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz#sha256=f08a4e276c3a1583a86dce3e34aba3fe04d02bba2dd51ed16106244e8a923e3b (from https://pypi.org/simple/docutils/)
  Running setup.py (path:/tmp/pip-build-U_uehq/docutils/setup.py) egg_info for package docutils
    Running command python setup.py egg_info
    /usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'python_requires'
      warnings.warn(msg)
    running egg_info
    creating pip-egg-info/docutils.egg-info
    writing pip-egg-info/docutils.egg-info/PKG-INFO
    writing top-level names to pip-egg-info/docutils.egg-info/top_level.txt
    writing dependency_links to pip-egg-info/docutils.egg-info/dependency_links.txt
    writing entry points to pip-egg-info/docutils.egg-info/entry_points.txt
    writing manifest file 'pip-egg-info/docutils.egg-info/SOURCES.txt'
    warning: manifest_maker: standard file '-c' not found

    package init file 'docutils/parsers/rst/include/__init__.py' not found (or not a regular file)
    package init file 'docutils/writers/s5_html/themes/__init__.py' not found (or not a regular file)
    package init file 'docutils/writers/s5_html/themes/default/__init__.py' not found (or not a regular file)
    reading manifest file 'pip-egg-info/docutils.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    warning: no previously-included files found matching 'test/alltests.out'
    warning: no previously-included files found matching 'test/record.txt'
    warning: no previously-included files matching '*.pyc' found anywhere in distribution
    warning: no previously-included files matching '*~' found anywhere in distribution
    warning: no previously-included files matching '__pycache__' found anywhere in distribution
    warning: no previously-included files matching '.DS_Store' found anywhere in distribution
    writing manifest file 'pip-egg-info/docutils.egg-info/SOURCES.txt'
  Source in /tmp/pip-build-U_uehq/docutils has version 0.20.1, which satisfies requirement docutils from https://files.pythonhosted.org/packages/1f/53/a5da4f2c5739cf66290fac1431ee52aff6851c7c8ffd8264f13affd7bcdd/docutils-0.20.1.tar.gz#sha256=f08a4e276c3a1583a86dce3e34aba3fe04d02bba2dd51ed16106244e8a923e3b
~~~

pip version 8.1.2
CentOS Linux 7 (Core)
Linux 3.10.0-1160.95.1.el7.x86_64


---

Sent from sourceforge.net because doc...@li... 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.

Re: [Docutils-develop] Some docutils.org links point to docutils.sourceforge.io

[Guenter M. <mi...@us...>]

On 2023-11-11, Jarret "Jax" Renker via Docutils-develop wrote:

> Some links from docutils.org point to docutils.sourceforge.io,
> e.g. the very first "Docutils" link in the top left of

>    https://www.docutils.org/docs/ref/rst/directives.html

Docutils documentation is hosted on sourceforge, therefore absolute links
to the documentation use docutils.sourceforge.io as base URL. 

I don't know who set up the "docutils.org" domain and who is in charge of
it. It does not seem to be malign, though.
Relative links will resolve to "www.docutils.org" if called from there.

Günter

[Docutils-develop] Some docutils.org links point to docutils.sourceforge.io

[Jarret \Jax\ R. <jar...@pr...>]

Hi,

Some links from docutils.org point to docutils.sourceforge.io,
e.g. the very first "Docutils" link in the top left of

   https://www.docutils.org/docs/ref/rst/directives.html

Regards
 Jax

[Docutils-develop] [docutils:bugs] #476 Using short pygments class names with HTML5 writer results in strings being struck-out

[Günter M. <mi...@us...>]

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

Thank you for the bug report and MWE.
It is fixed in [r9471].



---

**[bugs:#476] Using short pygments class names with HTML5 writer results in strings being struck-out**

**Status:** open-fixed
**Created:** Tue Nov 07, 2023 07:20 PM UTC by John Thorvald Wodder II
**Last Updated:** Tue Nov 07, 2023 07:20 PM UTC
**Owner:** nobody


When converting a reStructuredText document to HTML5 with the `--syntax-highlight=short` option, if any tokens in the highlighted code use the `s` class (for generic strings), docutils will render those tokens by wrapping them in `<s>...</s>`, producing struck-through text.

For example, given the following rST file:

```rst
.. code:: shell

    cat <<EOF
    Hello World!
    EOF
```

Running `docutils --syntax-highlight=short` on this file produces an HTML file containing the following:

```html
<pre class="code shell literal-block"><code>cat<span class="w"> </span><s><<EOT
Hello World!
EOT</s></code></pre>
```

Note the `<s>...</s>` around the heredoc, which is rendered as struck-through text.


---

Sent from sourceforge.net because doc...@li... 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.

Re: [Docutils-develop] Test failure: manpage writer

[engelbert g. <eng...@gm...>]

Hei

thanks for fixing my badness günter

On Sat, 4 Nov 2023 at 20:31, G. Branden Robinson <
g.b...@gm...> wrote:

> Hi Günter,
>
> At 2023-11-04T19:11:19-0000, Guenter Milde via Docutils-develop wrote:
> > thank you for the fast and comprehensive answer.
>
>
SNIP


> > > tbl(1):
> > >      allbox          Enclose each table entry in a box; implies box.
> >
> > This would be even cleaner and the preferred solution for tables
>

then i try again ... last time box worked but allbox no so good

> * if it is supported by all relevant workflows
>
>
> That, I cannot answer...
>
> > * if support is not too new.
>
> ...this, I can.  The "allbox" feature is documented as far back as the
> "tbl" white paper by Mike Lesk that was distributed with Seventh Edition
> Unix.  That's 1979.  :)
>
>
thanks for aiding

[Docutils-develop] [docutils:feature-requests] #98 Warn on title underline too long

[Günter M. <mi...@us...>]

- **status**: open --> pending



---

**[feature-requests:#98] Warn on title underline too long**

**Status:** pending
**Group:** Default
**Created:** Sat Oct 28, 2023 10:14 AM UTC by xypron
**Last Updated:** Sun Oct 29, 2023 10:45 AM UTC
**Owner:** nobody


If title underlines are too short, docutils creates a warning:

docutils/parsers/rst/states.py:2750:
        msg = self.reporter.warning('Title underline too short.', 

Many documentation projects want the underline to match the title. It would be great if we could have a warning for titles that are too long too.  Maybe some switch would be needed to disable the warning.



---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

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

[Docutils-develop] [docutils:feature-requests] #97 --disable-tab-expansion flag

[Günter M. <mi...@us...>]

A patch-set was posted to the "docutils-develop" mail list on 2023-10-29. See the thread in the [archive](https://sourceforge.net/p/docutils/mailman/docutils-develop/?viewmonth=202310).


---

**[feature-requests:#97] --disable-tab-expansion flag**

**Status:** open
**Group:** Default
**Created:** Sun Jul 16, 2023 09:21 AM UTC by toastal
**Last Updated:** Sun Jul 16, 2023 10:27 AM UTC
**Owner:** nobody


> Spaces are recommended for indentation, but tabs may also be used. Tabs will be converted to spaces. Tab stops are at every 8th column (processing systems may make this value configurable).

Why tho? By converting tabs to spaces, we lose the accessibility aspect that tabs provide by letting the reader decide what’s comfortable to them as tab-width should be configurable on the reader’s side, not the writer’s. Some programming languages, like Go, tabs are overwhelmingly preferred & sometimes even required. Copying some code would not work.

I would like to see a `--disable-tab-expansion` flag that lets the author choose how they want their output to be output.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

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

[Docutils-develop] [docutils:feature-requests] #96 <abbr> abbreviations tag

[Günter M. <mi...@us...>]

The `<abbr>` tag is already supported by the HTML5 writer, see https://docutils.sourceforge.io/test/functional/expected/standalone_rst_html5.html#text-level-semantics and the source
https://docutils.sourceforge.io/test/functional/input/data/html5-text-level-tags.txt.

However, there is currently no way to specify the expansion (the "title"). rST inline roles syntax is not suited for cases requiring 2 arguments (here, the title and the abbreviation).
Unfortunately, there is no clear solution:
https://docutils.sourceforge.io/docs/dev/rst/alternatives.html#parameterized-interpreted-text


---

**[feature-requests:#96] <abbr> abbreviations tag**

**Status:** open
**Group:** Default
**Created:** Wed Jul 12, 2023 06:19 AM UTC by toastal
**Last Updated:** Wed Jul 12, 2023 06:31 AM UTC
**Owner:** nobody


I would like to see inline support for `<abbr>` tags.

> The `abbr` element represents an abbreviation or acronym, optionally with its expansion. The `title` attribute may be used to provide an expansion of the abbreviation. The attribute, if specified, must contain an expansion of the abbreviation, and nothing else.

https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-abbr-element

These are useful for jargon-heavy content like documentation and can help with accessibility.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

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

[Docutils-develop] [docutils:feature-requests] #93 Mod operator for math2html

[Günter M. <mi...@us...>]

- **status**: pending --> closed-wont-fix



---

**[feature-requests:#93] Mod operator for math2html**

**Status:** closed-wont-fix
**Group:** Default
**Created:** Sat Sep 03, 2022 08:43 PM UTC by Daniel James Perry
**Last Updated:** Mon Jun 26, 2023 07:28 PM UTC
**Owner:** nobody


The latex to html/css code is quite impressive, but it's missing the `\\mod` command (as well as other similar commands like `\\pmod`. It should be a trivial thing to do.

BTW please get with the times and start using git PLEASE.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

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

[Docutils-develop] [docutils:bugs] #476 Using short pygments class names with HTML5 writer results in strings being struck-out

[John T. W. I. <jw...@us...>]

---

**[bugs:#476] Using short pygments class names with HTML5 writer results in strings being struck-out**

**Status:** open
**Created:** Tue Nov 07, 2023 07:20 PM UTC by John Thorvald Wodder II
**Last Updated:** Tue Nov 07, 2023 07:20 PM UTC
**Owner:** nobody


When converting a reStructuredText document to HTML5 with the `--syntax-highlight=short` option, if any tokens in the highlighted code use the `s` class (for generic strings), docutils will render those tokens by wrapping them in `<s>...</s>`, producing struck-through text.

For example, given the following rST file:

```rst
.. code:: shell

    cat <<EOF
    Hello World!
    EOF
```

Running `docutils --syntax-highlight=short` on this file produces an HTML file containing the following:

```html
<pre class="code shell literal-block"><code>cat<span class="w"> </span><s><<EOT
Hello World!
EOT</s></code></pre>
```

Note the `<s>...</s>` around the heredoc, which is rendered as struck-through text.


---

Sent from sourceforge.net because doc...@li... 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.

Re: [Docutils-develop] Test failure: manpage writer

[G. B. R. <g.b...@gm...>]

Hi Günter,

At 2023-11-04T19:11:19-0000, Guenter Milde via Docutils-develop wrote:
> thank you for the fast and comprehensive answer.

No worries; glad to be of help when I can.

> My patch adapts the "expected" output to what Docutils' manpage writer
> emits since the recent changes.
> 
> If I understand this right, then the changes work as intended, we can
> change the "expected" output sample and by this endorse the new
> manpage writer behaviour.

That sounds correct to me.  The change in groff 1.23.0's table
formatting for terminals was deliberate.  I didn't put this in the
"NEWS" file because there is no specification for tbl's behavior on
terminals with respect to whether box borders or vertical rules get
space "inboard" of them with respect to cell contents.

In fact, tbl(1) support on terminal devices is often neglected.
Documenter's Workbench troff and Heirloom Doctools troff produce fairly
dire output to terminals for anything but the simplest tables.

mandoc(1), by contrast, does fine (as does groff, of course).

> > Further, if you want a table where every cell is boxed, that's what
> > the "allbox" option is for.  You can use that instead of putting "|"
> > in your row descriptions and adding rows consisting solely of "_".
> 
> > tbl(1):
> >      allbox          Enclose each table entry in a box; implies box.
> 
> This would be even cleaner and the preferred solution for tables
> 
> * if it is supported by all relevant workflows

That, I cannot answer...

> * if support is not too new.

...this, I can.  The "allbox" feature is documented as far back as the
"tbl" white paper by Mike Lesk that was distributed with Seventh Edition
Unix.  That's 1979.  :)

(If you can find a copy of _Unix Time-Sharing System Programmer's Manual
Seventh Edition Volume 2A_ online, you'll find this region option
documented on or near page 155.)

Again, terminal output using DWB or Heirloom nroff is bad, but it's bad
either way, and has been for as long as the Python docutils have
existed.  My experiments show that "allbox" makes it neither better or
worse; I suspect the problem lies with computations around the line
drawing operations themselves.

Regards,
Branden

Re: [Docutils-develop] Test failure: manpage writer

[Guenter M. <mi...@us...>]

Dear Branden,

thank you for the fast and comprehensive answer.

On 2023-11-03, G. Branden Robinson wrote:
> At 2023-11-03T18:15:33-0000, Guenter Milde via Docutils-develop wrote:


>> running the test suite with r9464 resulted in a failure

>> FAIL: test_publish (test_writers.test_manpage.WriterPublishTestCase)
>>       (id="totest['table'][0]")
> [...]
>> It this the intended output?
>> Is it tested with groff?

> The output of groff in 1.23.0 changed slightly here.
> Here's some 1.22.4/1.23.0 comparison on my system.  UTF-8 output
> follows.

...

> A.  Fewer blank lines in the output after the page header; and
> B.  There is now a space after the left border of the table.

My patch adapts the "expected" output to what Docutils' manpage writer emits
since the recent changes.

If I understand this right, then the changes work as intended,
we can change the "expected" output sample and
by this endorse the new manpage writer behaviour.

...

> Further, if you want a table where every cell is boxed, that's what the
> "allbox" option is for.  You can use that instead of putting "|" in your
> row descriptions and adding rows consisting solely of "_".

> tbl(1):
>      allbox          Enclose each table entry in a box; implies box.

This would be even cleaner and the preferred solution for tables

* if it is supported by all relevant workflows
* if support is not too new.

Thanks again,

Günter

Re: [Docutils-develop] Test failure: manpage writer

[G. B. R. <g.b...@gm...>]

Hi Guenter,

I'm CCing you because it seems like everytime I post to this list, I get
a bounce telling me I'm not subscribed.  But I am...

At 2023-11-03T18:15:33-0000, Guenter Milde via Docutils-develop wrote:
> Dear Engelbert,
> 
> running the test suite with r9464 resulted in a failure
> 
> FAIL: test_publish (test_writers.test_manpage.WriterPublishTestCase)
>       (id="totest['table'][0]")
[...]
> It this the intended output?
> Is it tested with groff?

The output of groff in 1.23.0 changed slightly here.

Here's some 1.22.4/1.23.0 comparison on my system.  UTF-8 output
follows.

$ /usr/bin/nroff -v
GNU nroff (groff) version 1.22.4
$ nroff -v
GNU nroff (groff) version 1.23.0
GNU groff version 1.23.0
Copyright (C) 2022 Free Software Foundation, Inc.
GNU groff comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of groff and its subprograms
under the terms of the GNU General Public License.
For more information about these matters, see the file
named COPYING.

called subprograms:

GNU grotty (groff) version 1.23.0
GNU troff (groff) version 1.23.0

First let's look at how the original table exhibit is handled.

$ cat /tmp/docu.man
.TH foo 1 2023-11-03 "groff test suite"
.SH Name
foo \- frobnicate a bar
.TS
center;
|l|l|.
_
T{
head
T}      T{
and
T}
_
T{
1
T}      T{
2
T}
_
T{
abc
T}      T{
so
T}
_
.TE

$ /usr/bin/nroff -t -man /tmp/docu.man
foo(1)                      General Commands Manual                     foo(1)



Name
       foo - frobnicate a bar
                                    ┌─────┬─────┐
                                    │head │ and │
                                    ├─────┼─────┤
                                    │1    │ 2   │
                                    ├─────┼─────┤
                                    │abc  │ so  │
                                    └─────┴─────┘



groff test suite                  2023‐11‐03                            foo(1)
$ nroff -t -man /tmp/docu.man
foo(1)                      General Commands Manual                     foo(1)

Name
       foo - frobnicate a bar
                                   ┌──────┬─────┐
                                   │ head │ and │
                                   ├──────┼─────┤
                                   │ 1    │ 2   │
                                   ├──────┼─────┤
                                   │ abc  │ so  │
                                   └──────┴─────┘

groff test suite                  2023‐11‐03                            foo(1)

Notice:

A.  Fewer blank lines in the output after the page header; and
B.  There is now a space after the left border of the table.

With your patch, let see what we get.

$ cat /tmp/docu2.man
.TH foo 1 2023-11-03 "groff test suite"
.SH Name
foo \- frobnicate a bar
.TS
box center;
l|l.
T{
head
T}      T{
and
T}
_
T{
1
T}      T{
2
T}
_
T{
abc
T}      T{
so
T}
.TE
$ /usr/bin/nroff -t -man /tmp/docu2.man
foo(1)                      General Commands Manual                     foo(1)



Name
       foo - frobnicate a bar
                                    ┌─────┬─────┐
                                    │head │ and │
                                    ├─────┼─────┤
                                    │1    │ 2   │
                                    ├─────┼─────┤
                                    │abc  │ so  │
                                    └─────┴─────┘


groff test suite                  2023‐11‐03                            foo(1)
$ nroff -t -man /tmp/docu2.man
foo(1)                      General Commands Manual                     foo(1)

Name
       foo - frobnicate a bar
                                   ┌──────┬─────┐
                                   │ head │ and │
                                   ├──────┼─────┤
                                   │ 1    │ 2   │
                                   ├──────┼─────┤
                                   │ abc  │ so  │
                                   └──────┴─────┘

groff test suite                  2023‐11‐03                            foo(1)

Notice again:

A.  Fewer blank lines in the output after the page header; and
B.  There is now a space after the left border of the table.

I fixed several bugs in table formatting for terminal devices in groff
1.23.0, and while I was at it I made the box border handling more
consistent.

Here's the relevant commit.

commit 8f066786ea3cb5e1dbade1149e7d50ae978da202
Author: G. Branden Robinson <g.b...@gm...>
Date:   Fri Feb 3 02:22:02 2023 -0600

    [tbl]: Improve symmetry of tables in nroff mode.

    * src/preproc/tbl/table.cpp (table::compute_column_positions): If a
      table has "left separation" (it is boxed, or has a vertical rule on
      the left-hand side), increase the first column's start register value
      by 1n, for symmetry with the right-hand size.

    * src/preproc/tbl/tests/check-horizontal-line-length.sh:
    * src/preproc/tbl/tests/check-line-intersections.sh:
    * src/preproc/tbl/tests/check-vertical-line-length.sh: Update output
      expectations.

    * src/preproc/tbl/tbl.am (tbl_XFAIL_TESTS): Remove now-passing test.

    Before:

    +--+---+---+
    |a | b | c |
    +--+---+---+
    |d | e | f |
    +--+---+---+
    |g | h | i |
    +--+---+---+

    After:

    +---+---+---+
    | a | b | c |
    +---+---+---+
    | d | e | f |
    +---+---+---+
    | g | h | i |
    +---+---+---+

Further, if you want a table where every cell is boxed, that's what the
"allbox" option is for.  You can use that instead of putting "|" in your
row descriptions and adding rows consisting solely of "_".

tbl(1):
     allbox          Enclose each table entry in a box; implies box.

Regards,
Branden

[Docutils-develop] Test failure: manpage writer

[Guenter M. <mi...@us...>]

Dear Engelbert,

running the test suite with r9464 resulted in a failure

FAIL: test_publish (test_writers.test_manpage.WriterPublishTestCase)
      (id="totest['table'][0]")

The following patch fixes it:



diff --git a/docutils/test/test_writers/test_manpage.py b/docutils/test/test_writers/test_manpage.py
index e13adedc3..9ed182c33 100644
--- a/docutils/test/test_writers/test_manpage.py
+++ b/docutils/test/test_writers/test_manpage.py
@@ -20,6 +20,9 @@
 
 
 class WriterPublishTestCase(unittest.TestCase):
+    
+    maxDiff = None
+    
     def test_publish(self):
         writer_name = 'manpage'
         for name, cases in totest.items():
@@ -251,9 +254,8 @@ def test_publish(self):
 .INDENT 0.0
 .INDENT 3.5
 .TS
-center;
-|l|l|.
-_
+box center;
+l|l.
 T{
 head
 T}\tT{
@@ -271,7 +273,6 @@ def test_publish(self):
 T}\tT{
 so
 T}
-_
 .TE
 .UNINDENT
 .UNINDENT


It this the intended output?
Is it tested with groff?

Günter

Re: [Docutils-develop] [docutils:feature-requests] Re: #100 Support SVG hyperlinks and event handling

[Karl O. P. <ko...@ka...>]

On Thu, 02 Nov 2023 00:03:36 -0000
engelbert gruber via Docutils-develop
<doc...@li...> wrote:

> at least an example of what you want would be really helpful

Here's a random web page with SVG that responds to events:
https://www.tutorialspoint.com/svg/svg_interactivity.htm

Note that it is not, at the same time, resizeable depending
on browser window size.  (See below.)

Here's another with SVG that contains a hyperlink:
https://developer.mozilla.org/en-US/docs/Web/SVG/Element/a

Is this what you were asking for?

SVG files called up in a browser using a file:/// URL
also are scriptable and hyperlinkable.  I could surely
find some SVG file and attach it if that's helpful.

> a discussion of 10+ pages is no specification, is it ?

There is nothing to specify that is RST author-facing.  All the
design work would be implementation.  At least ideally,
since there's no need for any more RST options.  SVG
has hyperlinks and responds to events by virtue of
being SVG.

The 2 new desired behaviors are:
  be scriptable (respond to keyboard, mouse, and document events)
  support hyperlinks in the image

The 2 existing behaviors to retain are:
  be dynamically re-sizeable to browser window size
  not need a separate copy each time the SVG appears in a web page
    (be able to refer to a SVG file via a "href="-like mechanism)

The last is not really required, but sure would be nice.  I want all
of the above behaviors to be available at the same time in the
same SVG image.


I tried coming up with an implementation and was not entirely
successful.  Here's what I found:

If the image file for RST image or figure directives
is SVG render with the HTML "svg" element, 
otherwise render with the "img" element.

As near as I can tell, if you want your SVG to have
hyperlinks or respond to events the browser's require
the use of the "svg" element.  (Other elements
like "object" work too but have problems I can't
now remember, perhaps having to do with events
happening to the SVG being unavailable to the
outer DOM.)

As it turns out, the SVG "image" element won't produce
something interactive, following clicked on hyperlinks
or responding to events.  I don't really know how to
make an SVG image in an external file size dynamically and,
at the same time, be interactive.  Or whether it's possible to
re-use SVG files by way of "href="-like linking or if the
SVG would have to be embedded in the HTML.  Ideas follow.


You would think that the SVG "use" element (which has
a "href" attribute) would allow re-use of
an entire SVG file, but apparently not.  One work-around might
be to open the SVG file, extract the "svg" element's
opening and closing tags for use in the HTML, re-write
the SVG file putting a group around the entire content,
then put a SVG "use" element in the "svg" element in the
HTML and have it use the new group.  That would get the
original viewBox attribute into the HTML so that scaling the image
size would work, and the "use" element means that interactivity
is available.  This seems like a kludge, but seems like it would work.

(Sphinx, at least, copies image files into its build directory.
Modifying the copied files seems not unreasonable.  If docutils
rejects this feature request because it does not want to modify
files that's a reason to push the request back into the
Sphinx space.)

One would think there's a better way.  Surely somebody wants
to reference (href) a SVG file in their HTML, and have it be both
dynamically re-sizeable and interactive.  But I can't
find an example that does all 3 -- only embedding SVG
in HTML, not referencing an existing file via "href=",
seems to be what people do.  I suppose RST could embed SVG too,
but that also seems clunky.

So that's 2 possible approaches.  Embed the SVG file directly
in the HTML, or re-write the SVG file so that the SVG "use" element
can reference the file's content.

Regards,

Karl <ko...@ka...>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

[Docutils-develop] [docutils:feature-requests] Re: #100 Support SVG hyperlinks and event handling

[engelbert g. <gr...@us...>]

at least an example of what you want would be really helpful

a discussion of 10+ pages is no specification, is it ?

On Wed, 1 Nov 2023 at 22:19, Karl O. Pinc <kp...@us...>
wrote:

> See also, the releated Sphinx bug:
> https://github.com/sphinx-doc/sphinx/issues/2240
> ------------------------------
>
> *[feature-requests:#100]
> <https://sourceforge.net/p/docutils/feature-requests/100/> Support SVG
> hyperlinks and event handling*
>
> *Status:* open
> *Group:* Default
> *Created:* Wed Nov 01, 2023 09:15 PM UTC by Karl O. Pinc
> *Last Updated:* Wed Nov 01, 2023 09:15 PM UTC
> *Owner:* nobody
>
> SVG supports embedded hyperlinks, and the ability to trigger scripts on
> keyboard, mouse, and document events. But docutils does not, because SVG
> files are referenced by HTML "img" elements instead of "svg" elements.
>
> Might be best to use the SVG "image" element, nested in a HTML "svg"
> element, to reference the underlying SVG file.
> ------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/docutils/feature-requests/100/
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/
>



---

**[feature-requests:#100] Support SVG hyperlinks and event handling**

**Status:** open
**Group:** Default
**Created:** Wed Nov 01, 2023 09:15 PM UTC by Karl O. Pinc
**Last Updated:** Wed Nov 01, 2023 09:19 PM UTC
**Owner:** nobody


SVG supports embedded hyperlinks, and the ability to trigger scripts on keyboard, mouse, and document events.  But docutils does not, because SVG files are referenced by HTML "img" elements instead of "svg" elements.

Might be best to use the SVG "image" element, nested in a HTML "svg" element, to reference the underlying SVG file.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

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

[Docutils-develop] [docutils:bugs] #475 man output produces broken tables

[engelbert g. <gr...@us...>]

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

thanks for reporting



---

**[bugs:#475] man output produces broken tables**

**Status:** closed-accepted
**Labels:** manpage writer 
**Created:** Mon Sep 25, 2023 03:57 PM UTC by Kovid Goyal
**Last Updated:** Tue Oct 31, 2023 02:16 PM UTC
**Owner:** engelbert gruber


The docutils.writers.manpage.Table class produces suboptimal table markup that causes display issues depending on terminal window size. This is because of the way the external table borders are specified.
Currently the class uses | and _ to generate lines for the external borders. The correct way to do it is to use the "box" option. If you do that, groff will take care of generating the external border itself and this one renders properly in terminals. I have monkeypatched the Table class in my project to do this, here is the code: https://github.com/kovidgoyal/kitty/blob/master/docs/conf.py#L550




---

Sent from sourceforge.net because doc...@li... 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.

[Docutils-develop] [docutils:feature-requests] #99 Support scaleable images in html (along with other SVG features)

[Günter M. <mi...@us...>]

- **status**: open --> closed-works-for-me
- **Comment**:

Closing as the main request (scaling) is satisfied (but see also [feature-requests:#57])

For the somewhat related topic of "interactivity", please open a new issue.
I would like to support "directly embedded" SVG but the devil is in the detail (how to handle the various image directive options). This would need more testing and understanding to get it right.



---

**[feature-requests:#99] Support scaleable images in html (along with other SVG features)**

**Status:** closed-works-for-me
**Group:** Default
**Created:** Sat Oct 28, 2023 10:02 PM UTC by Karl O. Pinc
**Last Updated:** Mon Oct 30, 2023 03:45 PM UTC
**Owner:** nobody


Scaleable images formats (i.e. SVG) should be scaleable in those output formats (i.e. HTML) where the page size is not fixed (i.e. a web browser).

A major benefit of SVG is that it scales.  Make the window bigger or smaller and the image adjusts accordingly.  RST does not seem to support this.  (See link at bottom for a work-around using "raw".  But the work-around works only for images, not figures.)

It would be nice if the image and figure directives allowed the "scale:" option to take the values "width" and "height".  These would allow the image to scale to the width or height of the browser's window while maintaining the image's aspect ratio.  These 2 new values can be ignored when generating output with fixed page sizes.

Alternately, introduce a new option.   (resize?)  Doing so would side-step the issue of how to specify option values that vary depending on the chosen output format.

It seems  that the right way to implement this is by generating an inline HTML svg tag that contains an SVG image tag referencing the svg file which is to be part of the document.  CSS can then control how the scaling is done.

A related matter is the ability to have interactive SVG documents, which respond to keyboard, pointer, and document events.  Apparently, these features are not realizable when embedding SVG with a HTML image tag.  This is another argument for an inline HTML svg tag.

Finally, SVG supports embedded hyperlinks.  I'm unclear on whether this is "interactive" or not but wouldn't want to forgo the ability to click on a portion of a diagram and be taken to the relevant section in the documentation.  (It seems hyperlinks are an SVG 2.0 feature.  But the feature does seem to be supported for SVG v1.1 generaed by Inkscape and displayed in a browser.)

See also the following Sphinx bug:
https://github.com/sphinx-doc/sphinx/issues/2240




---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

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

Re: [Docutils-develop] [PATCH 0/9] Allow literal tabs in reStructuredText

[engelbert g. <eng...@gm...>]

mind you ... this is a discussion

On Tue, 31 Oct 2023 at 19:12, Jarret "Jax" Renker <
jar...@pr...> wrote:

> Hi,
>
> ------- Original Message -------
> On Tuesday, October 31st, 2023 at 1:49 PM, engelbert gruber <
> eng...@gm...> wrote:
> > thinking about tabs
> >
> > * python discourages usage hardtabs and space mixing, because becomes
> painful (IMHO)
>
> Sure, but other languages, e.g. Makefile, mandate tabs and so do some
> styleguides.
>
> > * python philosophy : explicit is better then implicit ... would an
> option :hard-tabs: keep
> > be more in line ?
>
> I'm fine with that.  I planned (re)using the tab_width option of
> docutils.conf (setting it to -1 preserves tabs, like its cousin does for
> the include directive) but introducing a new option is also ok.
>
>
> Regards,  Jax
>

Re: [Docutils-develop] [PATCH 0/9] Allow literal tabs in reStructuredText

[Jarret \Jax\ R. <jar...@pr...>]

Hi,

------- Original Message -------
On Tuesday, October 31st, 2023 at 1:49 PM, engelbert gruber <eng...@gm...> wrote:
> thinking about tabs
> 
> * python discourages usage hardtabs and space mixing, because becomes painful (IMHO)

Sure, but other languages, e.g. Makefile, mandate tabs and so do some styleguides.

> * python philosophy : explicit is better then implicit ... would an option :hard-tabs: keep
> be more in line ?

I'm fine with that.  I planned (re)using the tab_width option of docutils.conf (setting it to -1 preserves tabs, like its cousin does for the include directive) but introducing a new option is also ok.


Regards,  Jax