You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(27) |
Jun
(22) |
Jul
(72) |
Aug
(82) |
Sep
(86) |
Oct
(138) |
Nov
(100) |
Dec
(62) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(122) |
Feb
(147) |
Mar
(92) |
Apr
(82) |
May
(101) |
Jun
(153) |
Jul
(37) |
Aug
(34) |
Sep
(46) |
Oct
(46) |
Nov
(6) |
Dec
(38) |
2004 |
Jan
(64) |
Feb
(81) |
Mar
(36) |
Apr
(194) |
May
(329) |
Jun
(272) |
Jul
(68) |
Aug
(74) |
Sep
(150) |
Oct
(57) |
Nov
(62) |
Dec
(63) |
2005 |
Jan
(78) |
Feb
(30) |
Mar
(137) |
Apr
(78) |
May
(54) |
Jun
(122) |
Jul
(72) |
Aug
(110) |
Sep
(80) |
Oct
(75) |
Nov
(125) |
Dec
(79) |
2006 |
Jan
(100) |
Feb
(15) |
Mar
(41) |
Apr
(67) |
May
(30) |
Jun
(11) |
Jul
(14) |
Aug
(22) |
Sep
(20) |
Oct
(14) |
Nov
(11) |
Dec
(15) |
2007 |
Jan
(17) |
Feb
(16) |
Mar
(35) |
Apr
(21) |
May
(33) |
Jun
(50) |
Jul
(12) |
Aug
(7) |
Sep
(2) |
Oct
(6) |
Nov
(5) |
Dec
(2) |
2008 |
Jan
(14) |
Feb
(20) |
Mar
(35) |
Apr
(9) |
May
(57) |
Jun
(21) |
Jul
(42) |
Aug
(4) |
Sep
(13) |
Oct
(76) |
Nov
(40) |
Dec
(55) |
2009 |
Jan
(26) |
Feb
(15) |
Mar
(3) |
Apr
(67) |
May
(32) |
Jun
(39) |
Jul
(59) |
Aug
(31) |
Sep
(59) |
Oct
(64) |
Nov
(21) |
Dec
(10) |
2010 |
Jan
(21) |
Feb
(3) |
Mar
(116) |
Apr
(33) |
May
(9) |
Jun
(28) |
Jul
(21) |
Aug
(23) |
Sep
(146) |
Oct
(70) |
Nov
(31) |
Dec
(57) |
2011 |
Jan
(33) |
Feb
(22) |
Mar
(11) |
Apr
(21) |
May
(51) |
Jun
(47) |
Jul
(35) |
Aug
(26) |
Sep
(25) |
Oct
(34) |
Nov
(61) |
Dec
(51) |
2012 |
Jan
(75) |
Feb
(31) |
Mar
(26) |
Apr
(16) |
May
(24) |
Jun
(24) |
Jul
(31) |
Aug
(46) |
Sep
(36) |
Oct
(28) |
Nov
(37) |
Dec
(21) |
2013 |
Jan
(16) |
Feb
(56) |
Mar
(31) |
Apr
(44) |
May
(45) |
Jun
(29) |
Jul
(38) |
Aug
(18) |
Sep
(12) |
Oct
(16) |
Nov
(21) |
Dec
(11) |
2014 |
Jan
(13) |
Feb
(14) |
Mar
(28) |
Apr
(7) |
May
(72) |
Jun
(33) |
Jul
(21) |
Aug
(1) |
Sep
(6) |
Oct
(14) |
Nov
(18) |
Dec
(22) |
2015 |
Jan
(23) |
Feb
(108) |
Mar
(76) |
Apr
(114) |
May
(60) |
Jun
(9) |
Jul
(8) |
Aug
(9) |
Sep
(42) |
Oct
(9) |
Nov
|
Dec
(7) |
2016 |
Jan
(6) |
Feb
(15) |
Mar
(7) |
Apr
|
May
(33) |
Jun
(3) |
Jul
(19) |
Aug
(12) |
Sep
(6) |
Oct
(16) |
Nov
(17) |
Dec
(125) |
2017 |
Jan
(66) |
Feb
(98) |
Mar
(29) |
Apr
(32) |
May
(63) |
Jun
(98) |
Jul
(26) |
Aug
(33) |
Sep
(19) |
Oct
(77) |
Nov
(31) |
Dec
(27) |
2018 |
Jan
(32) |
Feb
(11) |
Mar
(5) |
Apr
(12) |
May
(4) |
Jun
(9) |
Jul
(9) |
Aug
(13) |
Sep
(11) |
Oct
(6) |
Nov
(23) |
Dec
(2) |
2019 |
Jan
(26) |
Feb
(12) |
Mar
(20) |
Apr
(18) |
May
(7) |
Jun
(22) |
Jul
(81) |
Aug
(129) |
Sep
(32) |
Oct
(18) |
Nov
(11) |
Dec
(44) |
2020 |
Jan
(19) |
Feb
(10) |
Mar
(38) |
Apr
(4) |
May
(9) |
Jun
(15) |
Jul
(29) |
Aug
(79) |
Sep
(12) |
Oct
(22) |
Nov
(10) |
Dec
(37) |
2021 |
Jan
(16) |
Feb
(14) |
Mar
(20) |
Apr
(100) |
May
(21) |
Jun
(19) |
Jul
(13) |
Aug
(13) |
Sep
(37) |
Oct
(112) |
Nov
(64) |
Dec
(22) |
2022 |
Jan
(209) |
Feb
(38) |
Mar
(11) |
Apr
(10) |
May
(55) |
Jun
(104) |
Jul
(35) |
Aug
(10) |
Sep
(21) |
Oct
(21) |
Nov
(50) |
Dec
(12) |
2023 |
Jan
(6) |
Feb
|
Mar
(3) |
Apr
(41) |
May
(48) |
Jun
(9) |
Jul
(6) |
Aug
(25) |
Sep
(3) |
Oct
(22) |
Nov
(56) |
Dec
(12) |
2024 |
Jan
(5) |
Feb
(5) |
Mar
(38) |
Apr
(62) |
May
(12) |
Jun
(10) |
Jul
(3) |
Aug
(59) |
Sep
(2) |
Oct
(36) |
Nov
(14) |
Dec
(3) |
2025 |
Jan
(5) |
Feb
(19) |
Mar
(7) |
Apr
(65) |
May
(11) |
Jun
(13) |
Jul
(46) |
Aug
(16) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Adam T. <aat...@ou...> - 2022-09-08 14:19:08
|
Dear Günter, Docutils developers, > Adam Turner is now part of the Docutils developers group on Sourceforge, > commits to the repo and editiong tickets should work. I'm excited to continue supporting the project, thanks to Günter, Engelbert, all for your support. I've confirmed the access etc. works on SourceForge. Thanks, Adam |
From: Adam T. <aa-...@us...> - 2022-09-08 14:15:42
|
As an update, I have just added the draft conversion files in [r9119] to my sandbox, https://sourceforge.net/p/docutils/code/HEAD/tree/trunk/sandbox/aa-turner/git_conversion/ A --- ** [feature-requests:#58] Migration Docutils from SourceForge to Github** **Status:** pending **Group:** Default **Created:** Fri Feb 16, 2018 03:23 PM UTC by Yves Chevallier **Last Updated:** Wed Jun 01, 2022 06:26 PM UTC **Owner:** nobody Sourceforge is not really user friendly to report issues, propose pull-request and contribute to the project. I would like to know if it is possible to migrate Docutils to GitHub. --- 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. |
From: Guenter M. <mi...@us...> - 2022-09-08 13:12:51
|
Dear Adam, dear Docutils developers, Adam Turner is now part of the Docutils developers group on Sourceforge, commits to the repo and editiong tickets should work. Looking forward to a fruitfull cooperation, Günter Milde |
From: Günter M. <mi...@us...> - 2022-09-07 13:52:39
|
- **labels**: --> manpage writer --- ** [bugs:#458] Two issues regarding manpage writer and .TH** **Status:** open **Labels:** manpage writer **Created:** Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev **Last Updated:** Mon Sep 05, 2022 05:42 PM UTC **Owner:** nobody Dear docutils developers, I received two bug reports in Debian regarding the content of .TH macro in man pages: First bug — https://bugs.debian.org/1016527 — asks that the value of `--date` argument be used for the third argument of `.TH`, instead of putting it on a separate line (Generated on: YYYY-MM-DD). Second bug — https://bugs.debian.org/1018737 — asks that docutils not set fifth argument of `.TH` to empty string, but omit it completely and rely on the default value. Please see those bugs for more detailed descriptions (and some discussion, in the first bug). --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 12:47:12
|
- **labels**: manpage-writer --> manpage writer --- ** [bugs:#380] manpage writer does not add space after .B** **Status:** closed-accepted **Labels:** manpage writer **Created:** Fri Oct 18, 2019 03:18 PM UTC by Maarten **Last Updated:** Tue Mar 03, 2020 09:41 PM UTC **Owner:** engelbert gruber I'm using sphinx-argparse to generate a man page from an argparse object. The generated man page has no spaces after .B inserted. This causes `--option` to show up as `-option` or `-o` as `o` in the manual. I think the cause of this problem is in docutils because adding a space after `'.B'` at https://github.com/docutils-mirror/docutils/blob/e88c5fb08d5cdfa8b4ac1020dd6f7177778d5990/docutils/writers/manpage.py#L887 fixed the problem for me. (`'.B' -> '.B '`) I've created a reproducer using sphinx-argparse. This requires (at least) sphinx-argparse, sphinx and docutils. ``` cd /tmp rm -rf WORKDIR mkdir WORKDIR cd WORKDIR sphinx-quickstart $PWD --extensions sphinxarg.ext --sep -p option_bug -a author -r 0.1 -l en --no-batchfile --makefile cat >>source/conf.py <<EOF man_pages = [ ('cmd_main', 'tmpmain', 'tmpmain Documentation', ['name of author'], 1) ] import sys import os sys.path.insert(0, os.path.dirname(os.getcwd())) EOF mkdir pymodule touch pymodule/__init__.py cat >pymodule/tmpmain.py <<EOF #!/usr/bin/env python3 import argparse def my_func_that_returns_a_parser(): parser = argparse.ArgumentParser() parser.add_argument('foo', default=False, help='foo help') parser.add_argument('bar', default=False) parser.add_argument('--general', '-G', default=False, help='General option') subparsers = parser.add_subparsers() subparser = subparsers.add_parser('install', help='install help') subparser.add_argument('ref', type=str, help='foo1 help') subparser.add_argument('--upgrade', action='store_true', default=False, help='foo2 help') subparser.add_argument('-U', action='store_true', default=False, help='foo3 help') return parser if __name__ == '__main__': p = my_func_that_returns_a_parser() p.parse_args() EOF chmod a+x pymodule/tmpmain.py cat >source/index.rst <<EOF Welcome to pymodule's documentation! ==================================== .. toctree:: :maxdepth: 2 :caption: Contents: cmd_main EOF cat >source/cmd_main.rst <<EOF .. argparse:: :module: pymodule.tmpmain :func: my_func_that_returns_a_parser :prog: fancytool EOF make man man build/man/tmpmain.1 ``` --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 12:43:12
|
- **status**: open --> closed-fixed - **Comment**: Thank you for the report. The URLs were updated 2022-01-22 in [r8956]. Using Docutils 0.19 or a repository snapshot should solve your issue. --- ** [bugs:#455] Replace older http URL with newer https URL** **Status:** closed-fixed **Created:** Fri Aug 26, 2022 07:23 PM UTC by Kevin Cole **Last Updated:** Fri Aug 26, 2022 07:23 PM UTC **Owner:** nobody I'm moving a documents to a new site and have configured the site using recommendations for CSP. I'm finding that the HTML documents generated from reStructuredText source all contain references to the old URL http://docutils.sourceforge.net/. Would it be safe to update all of these to https://docutils.sourceforge.io/ since that's where the above redirects to? On the surface, it seems like an "easy fix" and would mean that the generated code no longer contains the insecure "http"... --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 12:12:26
|
- **labels**: s5 --> S5 writer --- ** [bugs:#292] S5: left/right key after left mouse click does nothing** **Status:** open **Labels:** S5 writer **Created:** Wed Feb 24, 2016 02:35 PM UTC by Christian Weiske **Last Updated:** Tue Mar 03, 2020 09:41 PM UTC **Owner:** nobody **Attachments:** - [s5-bug-left-after-click.diff](https://sourceforge.net/p/docutils/bugs/292/attachment/s5-bug-left-after-click.diff) (435 Bytes; text/x-patch) The S5 slideshow mode offers key navigation. When left-clicking a slide, I'm going to the next slide. Pressing the "left arrow" key does nothing. Only a second press on "left arrow" actually goes to the previous slide. After that, it's all fine and key presses work - until I left-click a slide again. Same with the right key, which should go to the next slide. "`function go()`" sets `number` to `0`, so it seems to be intented - but I don't know why. --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 12:11:15
|
- **labels**: manpage-writer --> manpage writer --- ** [bugs:#287] rst2man: comma after option argument is in bold** **Status:** closed-fixed **Labels:** manpage writer **Created:** Mon Dec 07, 2015 11:24 AM UTC by Dmitry Shachnev **Last Updated:** Tue Mar 03, 2020 09:41 PM UTC **Owner:** nobody [ Forwarded from [Debian #806601](https://bugs.debian.org/806601). ] With the following reStructuredText file: :::restructuredtext -f, --foo FOO -b n, --bar n BAR `rst2man` produces the following output: .B \-f\fP,\fB \-\-foo .BI \-b \ n\fP,\fB \ \-\-bar \ n I suppose `\fP` was intended to reset to the normal font; but in the `.BI` line it actually switches to the bold font. --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 12:10:15
|
- **labels**: manpage-writer --> manpage writer --- ** [bugs:#231] manpages on solarix** **Status:** open **Labels:** manpage writer **Created:** Mon Mar 18, 2013 08:59 AM UTC by engelbert gruber **Last Updated:** Tue Mar 03, 2020 09:41 PM UTC **Owner:** engelbert gruber on solaris the manpage generated from rst2man.txt does only show the NAME section. removing > .de1 rstReportMargin > \\$1 \\n[an-margin] > level \\n[rst2man-indent-level] > level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] > - > \\n[rst2man-indent0] > \\n[rst2man-indent1] > \\n[rst2man-indent2] > .. it began working. That at least gives me a workaround: > sed -e '/^\.de1 rstReportMargin/,/^\.\./d' fixes this (see docutils-develop 16.mar.2013) --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 12:09:48
|
- **labels**: manpage-writer --> manpage writer --- ** [bugs:#427] Inconsistent sentence spacing in man pages using rst2man.py** **Status:** open **Labels:** manpage writer **Created:** Wed Oct 13, 2021 07:00 PM UTC by jei23jkfd **Last Updated:** Fri Oct 29, 2021 08:44 PM UTC **Owner:** nobody ## Operating system info I'm running Docutils 0.18b2.dev r8848 with Python 3.9. ## Description of bug The roff language has a very subtle requirement. It enforces semantic line breaks. That is, any roff document must end a sentence with a line break. For example, this is incorrect: ~~~ This is a sentence. This is another sentence. ~~~ We have to insert a line break after each sentence: ~~~ This is a sentence. This is another sentence. ~~~ The semantic line breaks are used to add optional sentence spacing. It uses the line breaks to detect when a period (or question or exclamation mark) represents the end of a sentence and then adds an optional extra space when displaying it. The relevant documentation for groff(1) and mandoc(1) is at - https://www.gnu.org/software/groff/manual/groff.html#Sentences - https://mandoc.bsd.lv/man/roff.7.html#Sentence_Spacing ## Minimal example Here is a minimal example that shows how the reST man page writer has this bug: ~~~rst ### mwe ### a minimal example ################# :Date: October 13, 2021 :Manual section: 1 :Manual group: Testing Docutils :Version: mwe 0.1.0 Synopsis ======== | mwe [**-aq**] [**-b** *file*] [**\--long-long** *which*] *file \...* Description =========== To find the common attributes of a variety of objects, it is necessary to begin, by surveying the *objects* themselves in the concrete. Let us therefore advert successively to the various modes of action, and arrangements of human affairs, which are classed, by universal or widely spread opinion, as Just or as Unjust. The things well known to excite the sentiments associated with those names, are of a very multifarious character. I shall pass them rapidly in review, without studying any particular arrangement. The previous line will have been spaced with two spaces. Options ======= Its arguments are as follows: -a Do all. -q Be quiet. -b file Do everything to *file*. --long-meme which Chooses the long named *which*. Environment =========== mwe is not affected by environment variables. Exit status =========== mwe exits 0 on success. ~~~ If you convert this with `rst2man.py mwe.rst mwe.1` and view it with `man ./mwe.1` you will notice the issue easily: some sentences in the DESCRIPTION section end with 1 space and some sentences end with 2 spaces. ## Possible solutions The most complete solution would be to automatically detect where sentences end in the input and add line breaks as required in the man page output. This is what Pandoc does. However, it requires keeping a list of abbreviations for every language so as to not have false positives: you don't want to add a line break when someone uses "e.g.". Another solution would be to use the `.ss` macro to remove the extra space at the end of any sentences. Then Docutils wouldn't have to conform to roff syntax. However, this would not work with mandoc(1) as the developer of that program has decided not to support `.ss`. This is what Asciidoctor does. Please let me know if you have any questions. --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 11:24:11
|
- **Comment**: Can you provide a MWE (minimal working/failing example), please. I don't know where in the code (Docutils source code or LaTeX code?) I should look, so I cannot reproduce. --- ** [bugs:#456] Latex Blank lines in Block Math Environment** **Status:** open **Created:** Thu Sep 01, 2022 09:14 PM UTC by Daniel James Perry **Last Updated:** Thu Sep 01, 2022 09:14 PM UTC **Owner:** nobody The latex writer has a serious bug regarding block math displays. According to the book *More Math into Latex*: > No blank lines are permitted within an equation or equation* environment. But if you look at the code that's **exactly what it does.** The resulting Latex output is incorrect. Please fix this as soon as possible. BTW get with the times and start using git please. --- 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. |
From: Günter M. <mi...@us...> - 2022-09-07 11:18:10
|
Ticket moved from /p/docutils/bugs/457/ --- ** [feature-requests:#93] Mod operator for the HTML Parser** **Status:** open **Group:** None **Created:** Sat Sep 03, 2022 08:43 PM UTC by Daniel James Perry **Last Updated:** Wed Sep 07, 2022 11:18 AM 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. |
From: Günter M. <mi...@us...> - 2022-09-07 11:12:02
|
- **status**: open --> open-fixed --- ** [bugs:#453] [DOC] generic "admonition" directive also listed as specific** **Status:** open-fixed **Created:** Wed Jul 27, 2022 09:53 AM UTC by jfbu **Last Updated:** Sat Jul 30, 2022 07:09 PM UTC **Owner:** nobody I quite probably miss something obvious but [admonition directives documentation](https://docutils.sourceforge.io/docs/ref/rst/directives.html#admonitions) is not clear in so far as it lists "admonition" as a specific admonition type then describes it as being a generic type (which requires a title). --- 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. |
From: Dmitry S. <man...@us...> - 2022-09-05 17:42:50
|
> Regarding the second bug: will omitting the fifth argument of `.TH` work with all troff/manpage processors? I asked the original reporter. He answered: > AFAIK, it will work. The behavior may differ, in that groff(1) and > mandoc(1) produce a default text, while others may not produce any text > at all, but it should work. --- ** [bugs:#458] Two issues regarding manpage writer and .TH** **Status:** open **Created:** Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev **Last Updated:** Mon Sep 05, 2022 04:20 PM UTC **Owner:** nobody Dear docutils developers, I received two bug reports in Debian regarding the content of .TH macro in man pages: First bug — https://bugs.debian.org/1016527 — asks that the value of `--date` argument be used for the third argument of `.TH`, instead of putting it on a separate line (Generated on: YYYY-MM-DD). Second bug — https://bugs.debian.org/1018737 — asks that docutils not set fifth argument of `.TH` to empty string, but omit it completely and rely on the default value. Please see those bugs for more detailed descriptions (and some discussion, in the first bug). --- 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. |
From: Günter M. <mi...@us...> - 2022-09-05 16:20:33
|
Thank you for forwarding the bug reports. The "--date" command line argument (and "datestamp" configuration value) "Include a time/datestamp in the document footer." (https://docutils.sourceforge.io/docs/user/config.html#datestamp). They are generic Docutils options that should not be used with the "manpage" writer. The "date" value for the `.th` macro fetched from the "Date" field of the [docinfo](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#bibliographic-fields). See the test input "standalone_rst_manpage.txt" for an example. Regarding the second bug: will omitting the fifth argument of `.TH` work with all troff/manpage processors? --- ** [bugs:#458] Two issues regarding manpage writer and .TH** **Status:** open **Created:** Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev **Last Updated:** Mon Sep 05, 2022 11:13 AM UTC **Owner:** nobody Dear docutils developers, I received two bug reports in Debian regarding the content of .TH macro in man pages: First bug — https://bugs.debian.org/1016527 — asks that the value of `--date` argument be used for the third argument of `.TH`, instead of putting it on a separate line (Generated on: YYYY-MM-DD). Second bug — https://bugs.debian.org/1018737 — asks that docutils not set fifth argument of `.TH` to empty string, but omit it completely and rely on the default value. Please see those bugs for more detailed descriptions (and some discussion, in the first bug). --- 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. |
From: Dmitry S. <man...@us...> - 2022-09-05 11:13:24
|
--- ** [bugs:#458] Two issues regarding manpage writer and .TH** **Status:** open **Created:** Mon Sep 05, 2022 11:13 AM UTC by Dmitry Shachnev **Last Updated:** Mon Sep 05, 2022 11:13 AM UTC **Owner:** nobody Dear docutils developers, I received two bug reports in Debian regarding the content of .TH macro in man pages: First bug — https://bugs.debian.org/1016527 — asks that the value of `--date` argument be used for the third argument of `.TH`, instead of putting it on a separate line (Generated on: YYYY-MM-DD). Second bug — https://bugs.debian.org/1018737 — asks that docutils not set fifth argument of `.TH` to empty string, but omit it completely and rely on the default value. Please see those bugs for more detailed descriptions (and some discussion, in the first bug). --- 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. |
From: Günter M. <mi...@us...> - 2022-08-28 21:12:20
|
On 2022-08-27, Adam Turner via Docutils-develop wrote in gmane.text.docutils.devel: > Perhaps: "No borders around the table or cells" or "No borders around > and within the table"? The LaTeX writer documentation (latex.txt) has the "minimal version" borderless No borders. I'd prefer the more terse alternative "No borders around table cells". For me, "around cells" instead of "between cells" implies no border around the table. But I don't know how this is seen by native English speakers. After all, it is easy to try out: Run `docutils` on :: == == 00 01 10 11 == == .. class:: borderless == == 00 01 10 11 == == and spot the difference. --- ** [bugs:#454] [DOC] borderless option said to remove borders "around" table but removes every border** **Status:** open **Created:** Sat Aug 06, 2022 01:41 PM UTC by jfbu **Last Updated:** Sat Aug 27, 2022 09:14 PM UTC **Owner:** nobody I tested [borderless](https://docutils.sourceforge.io/docs/user/config.html#table-style) with `rst2html.py` and found out that produced table was literally "borderless" which contradicted what I had understood from the documentation: ``` borderless No borders around the table. ``` I was expecting no top, right, botttom and left borders but *all* borders of *all cells* are removed. However I am not educated enough in Tables so maybe my expectation was too ill-informed. Or I misunderstand "around", as I am not native speaker. --- 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. |
From: Adam T. <aa-...@us...> - 2022-08-27 21:14:03
|
Perhaps: "No borders around the table or cells" or "No borders around and within the table"? A --- ** [bugs:#454] [DOC] borderless option said to remove borders "around" table but removes every border** **Status:** open **Created:** Sat Aug 06, 2022 01:41 PM UTC by jfbu **Last Updated:** Sat Aug 27, 2022 09:10 PM UTC **Owner:** nobody I tested [borderless](https://docutils.sourceforge.io/docs/user/config.html#table-style) with `rst2html.py` and found out that produced table was literally "borderless" which contradicted what I had understood from the documentation: ``` borderless No borders around the table. ``` I was expecting no top, right, botttom and left borders but *all* borders of *all cells* are removed. However I am not educated enough in Tables so maybe my expectation was too ill-informed. Or I misunderstand "around", as I am not native speaker. --- 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. |
From: jfbu <jf...@us...> - 2022-08-27 21:10:33
|
LGTM. I used `no lines whatsoever` in a PR at Sphinx adding ``latex_table_style`` configuration to describe there the effect of ``'borderless'``. --- ** [bugs:#454] [DOC] borderless option said to remove borders "around" table but removes every border** **Status:** open **Created:** Sat Aug 06, 2022 01:41 PM UTC by jfbu **Last Updated:** Sat Aug 06, 2022 01:41 PM UTC **Owner:** nobody I tested [borderless](https://docutils.sourceforge.io/docs/user/config.html#table-style) with `rst2html.py` and found out that produced table was literally "borderless" which contradicted what I had understood from the documentation: ``` borderless No borders around the table. ``` I was expecting no top, right, botttom and left borders but *all* borders of *all cells* are removed. However I am not educated enough in Tables so maybe my expectation was too ill-informed. Or I misunderstand "around", as I am not native speaker. --- 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. |
From: Günter M. <mi...@us...> - 2022-08-27 19:27:28
|
On 2022-08-06, jfbu via Docutils-develop wrote in gmane.text.docutils.devel: > I was expecting no top, right, botttom and left borders but *all* > borders of *all cells* are removed. However I am not educated enough > in Tables so maybe my expectation was too ill-informed. Or I > misunderstand "around", as I am not native speaker. You are right, the documentation is misleading (while the name should say it). How about borderless Remove all borders. ? --- ** [bugs:#454] [DOC] borderless option said to remove borders "around" table but removes every border** **Status:** open **Created:** Sat Aug 06, 2022 01:41 PM UTC by jfbu **Last Updated:** Sat Aug 06, 2022 01:41 PM UTC **Owner:** nobody I tested [borderless](https://docutils.sourceforge.io/docs/user/config.html#table-style) with `rst2html.py` and found out that produced table was literally "borderless" which contradicted what I had understood from the documentation: ``` borderless No borders around the table. ``` I was expecting no top, right, botttom and left borders but *all* borders of *all cells* are removed. However I am not educated enough in Tables so maybe my expectation was too ill-informed. Or I misunderstand "around", as I am not native speaker. --- 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. |
From: Michal U. <xev...@us...> - 2022-08-15 22:04:50
|
First, sorry for a late response and overall inactivity but yeah, this is what I want. Thanks. Will write to Nikola maintainers about the feature. --- ** [feature-requests:#91] Include directive path argument should support a configurable root.** **Status:** open **Group:** Default **Created:** Tue May 03, 2022 04:03 PM UTC by Michal Urbanski **Last Updated:** Thu Aug 04, 2022 03:11 PM UTC **Owner:** nobody I'm building a static website using restructuredtext and I'm really annoyed by the lack of support for root-relative paths. I have already implemented multiple directive plugins for my website build process, some of which use external files in a different format. They use the convention that if a path begins with /, they are relative to the root directory of the project. IMO the requirement for relative paths is very limiting - I could have a directory with files intended for inclusion but: - I would need to use `../../` which is very ugly - relative paths are different depending on the current file path - this is very fragile and limits An additional argument is that C and C++ have been using #include for like 40 years and relative paths (while sometimes useful) are only for specific cases. The leading convention is to use root-relative paths. I could implement another plugin for it but ... copy-pasting docutils own code only to change few lines is definitely smelly. --- 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. |
From: jfbu <jf...@us...> - 2022-08-06 13:41:21
|
--- ** [bugs:#454] [DOC] borderless option said to remove borders "around" table but removes every border** **Status:** open **Created:** Sat Aug 06, 2022 01:41 PM UTC by jfbu **Last Updated:** Sat Aug 06, 2022 01:41 PM UTC **Owner:** nobody I tested [borderless](https://docutils.sourceforge.io/docs/user/config.html#table-style) with `rst2html.py` and found out that produced table was literally "borderless" which contradicted what I had understood from the documentation: ``` borderless No borders around the table. ``` I was expecting no top, right, botttom and left borders but *all* borders of *all cells* are removed. However I am not educated enough in Tables so maybe my expectation was too ill-informed. Or I misunderstand "around", as I am not native speaker. --- 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. |
From: Günter M. <mi...@us...> - 2022-08-04 15:11:19
|
A first attempt. Configurable root directory for "include" and "raw" directives. Still lacking: test cases, handling of other included files (csv-table, images). --- ** [feature-requests:#91] Include directive path argument should support a configurable root.** **Status:** open **Group:** Default **Created:** Tue May 03, 2022 04:03 PM UTC by Michal Urbanski **Last Updated:** Fri May 20, 2022 05:56 PM UTC **Owner:** nobody I'm building a static website using restructuredtext and I'm really annoyed by the lack of support for root-relative paths. I have already implemented multiple directive plugins for my website build process, some of which use external files in a different format. They use the convention that if a path begins with /, they are relative to the root directory of the project. IMO the requirement for relative paths is very limiting - I could have a directory with files intended for inclusion but: - I would need to use `../../` which is very ugly - relative paths are different depending on the current file path - this is very fragile and limits An additional argument is that C and C++ have been using #include for like 40 years and relative paths (while sometimes useful) are only for specific cases. The leading convention is to use root-relative paths. I could implement another plugin for it but ... copy-pasting docutils own code only to change few lines is definitely smelly. --- 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. |
From: Guenter M. <mi...@us...> - 2022-08-04 11:49:46
|
Dear docutils developers, On 2022-02-22, Adam Turner wrote: > As advised by Günter Milde off-list, I'm submitting this request to > become a Project Developer. ... > I believe in absence of any other process that the decision over > accepting me (or not!) would fall to David Goodger as "BDFN", but I > welcome comment from anyone on my suitability. It is almost half a year since Adam's application and David seems to be taken up by other tasks. In my role as caretaker, I would add Adam Turner to the Docutils developers group on Sourceforge in a month (after the summer break) -- unless there is an objection (in private mail or here on the list) either against this way of moving forward or against the applicant or a suggestion for a better alternative process. Sincerely, Günter Milde |
From: Günter M. <mi...@us...> - 2022-08-04 11:36:42
|
- **labels**: --> LaTeX --- ** [patches:#183] Fix spacing around `code` and `raw` blocks in `compound` blocks** **Status:** pending-remind **Group:** None **Labels:** LaTeX **Created:** Mon Aug 16, 2021 08:17 PM UTC by Clément Pit-Claudel **Last Updated:** Tue May 03, 2022 10:52 AM UTC **Owner:** nobody **Attachments:** - [1-visit-inline.patch](https://sourceforge.net/p/docutils/patches/183/attachment/1-visit-inline.patch) (2.5 kB; text/x-patch) - [2-compound-code.patch](https://sourceforge.net/p/docutils/patches/183/attachment/2-compound-code.patch) (2.1 kB; text/x-patch) - [3-compound-raw.patch](https://sourceforge.net/p/docutils/patches/183/attachment/3-compound-raw.patch) (766 Bytes; text/x-patch) - [compound.rst](https://sourceforge.net/p/docutils/patches/183/attachment/compound.rst) (629 Bytes; text/x-rst) I have attached three patches and a test related to spaces before `raw` and `code` blocks. - `1-visit-inline.patch`: This is a small code simplification - `2-compound-code.patch`: This removes an unconditional newline added in compound blocks before code blocks that have a `:name:` - `3-compound-raw.patch`: This removes an unconditional newline added in compound blocks before raw blocks. - `compound.rst`: This is a test; I wasn't sure where to add it. It shows how things are modified by --- Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options. Or, if this is a mailing list, you can unsubscribe from the mailing list. |