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
(1) |
Oct
|
Nov
|
Dec
|
From: Günter M. <mi...@us...> - 2024-09-11 07:30:30
|
- **status**: pending --> open-fixed - **Comment**: Fixed in [r9928]. Thank you for the report and discussion. --- **[feature-requests:#102] Image height/width attributes** **Status:** open-fixed **Group:** Default **Created:** Wed Dec 20, 2023 02:35 PM UTC by toastal **Last Updated:** Sun Apr 07, 2024 05:08 PM UTC **Owner:** nobody When setting `:width:` or `:height:` on an image, the output is a `<image style="width: $W; height: $H">`. This isn’t the expected out put as there are & have been `width` & `height` attributes for the `<img>` tag for a long time. One might assume this is the same affect, but there are some important problems & why I think this is a bug for incorrect implementation. 1. Tools like Lighthouse, et al. show users to have width/height as a optimization so the browser can calculate & the image size properly without having to do a layout shift which is great 2. A good CSP (Content Security Policy) should never include `unsafe-inline` as this can be an attack surface but the output of `:width:` & `:height:` do just this. The way to solve this to keep out unneeded inline style practice for good CSP but still have the width/height is to just use `<img width="$W" height="$H">` (at least when units are not specified). What I may not be accounting for: units. `12px` is not the same as `12rem` or `12ex` or `12vw`. However, what I had input in my image was just plain ol’ integers got back something I didn’t expect: a) something using `px` (I‘m exclusively using relative unit like `em`, `rem`, etc.) and b) not using the attributes since the number I gave had no units. --- 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...> - 2024-08-31 11:04:45
|
- **status**: open --> closed-out-of-date - **Group**: --> None - **Comment**: As an "image map" is only supported by HTML output and a rarely used feature, the cost of increased complexity and documentation needs exceeds the benefits for Docutils. Possible workarounds are raw HTML and embedded SVG images (cf. the solved [feature-requests:#100]). --- **[patches:#61] Add usemap option to image directive** **Status:** closed-out-of-date **Group:** None **Created:** Sat Jul 18, 2009 05:23 AM UTC by Leandro Lucarella **Last Updated:** Sat Jul 18, 2009 05:23 AM UTC **Owner:** nobody The option is needed to easily plug an image map to a reST image. This is useful even when no 'imagemap' directive is implemented yet, because the image map can be written by hand using a 'raw' directive and for plug-ins that generate their own images using an image map \(aafigure, for instance\). --- 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. |
From: Günter M. <mi...@us...> - 2024-08-31 10:50:14
|
- **status**: open --> closed-wont-fix - **Group**: --> None --- **[patches:#66] patch to make figure and table captions hyperlink targets** **Status:** closed-wont-fix **Group:** None **Created:** Wed Nov 25, 2009 06:10 PM UTC by Terry Brown **Last Updated:** Wed Nov 25, 2009 06:10 PM UTC **Owner:** nobody This patch makes figure and table captions hyperlink targets. It was difficult to set the \label\{\} inserted into the latex longtable in the required place \(after the \caption, but not at the end where it added trailing garbage\) so the patch assumes the id in get\_caption\(\). Only HTML and \(old\)latex supported. --- 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. |
From: Günter M. <mi...@us...> - 2024-08-31 10:45:29
|
The syntax implemented in the proposed patch has one drawback explained by David Goodger in the original [docutils-users thread](https://sourceforge.net/p/docutils/mailman/docutils-users/thread/F40...@ti.../): > Perhaps we could define definition list items as one term per line, so this input: term 1 term 2 definition > would produce this output: <definition_list> <definition_list_item> <term> term 1 <term> term 2 <definition> <paragraph> definition > The current output is: <paragraph> term 1 term 2 <system_message level="3" line="3" source="<stdin>" type="ERROR"> <paragraph> Unexpected indentation. <block_quote> <paragraph> definition > I think this type of mistake is currently quite common. For example, a paragraph followed immediately (no blank line) by an indented bullet list. If we make this change to definition lists a lot of those helpful errors will disappear, and potentially unhelpful definition lists will take their place. Will the new behavior seem surprising or ambiguous? --- **[patches:#95] Multiterm definition items** **Status:** open **Group:** **Created:** Tue Jul 31, 2012 08:38 AM UTC by Kirill Smelkov **Last Updated:** Thu Jun 06, 2024 08:26 PM UTC **Owner:** nobody Following discussion on docutils-users about multi-term definition list items \[1,2\], I'am also posting my patches here, just to make sure they don't get lost. Thanks, Kirill \[1\] https://sourceforge.net/mailarchive/forum.php?thread\_name=F406FAD0-FC0D-425E-B9DB-EC6D959E8371%40tibsnjoan.co.uk&forum\_name=docutils-users \[2\] http://permalink.gmane.org/gmane.text.docutils.user/6765 --- 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. |
From: Günter M. <mi...@us...> - 2024-08-31 10:35:46
|
A possible syntax for reStructuredText input of multi-term definition lists is proposed in [patches:#95]. --- **[feature-requests:#60] Allow definition_list_item to have multiple terms** **Status:** open-fixed **Group:** Default **Created:** Thu Jan 03, 2019 09:10 AM UTC by Takeshi KOMIYA **Last Updated:** Fri Jun 07, 2024 09:30 PM UTC **Owner:** nobody **Attachments:** - [support_multiple_terms_on_definition_list_item.patch](https://sourceforge.net/p/docutils/feature-requests/60/attachment/support_multiple_terms_on_definition_list_item.patch) (3.7 kB; application/octet-stream) In HTML spec, definition list accepts multiple terms in a item. This patch allows doctree model to have multiple terms as children of definition_list_item also. https://www.w3.org/TR/html52/grouping-content.html#the-dl-element In sphinx, a custom directive named "glossary" allows multiple terms for one definition_list_item. https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#glossary --- 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...> - 2024-08-30 12:38:01
|
- **status**: open --> closed-fixed - **Group**: --> Default - **Comment**: Fixed by appliying [patches:47]. --- **[feature-requests:#18] Attributes in the main document are overriden** **Status:** closed-fixed **Group:** Default **Created:** Thu Mar 26, 2009 04:29 PM UTC by Jeffrey C. Jacobs **Last Updated:** Wed Jan 28, 2015 11:56 AM UTC **Owner:** nobody Any attributes set to the root document node are lost during a Title Promotion transformation because the update function is called instead of merging the attributes of the section into the document. For example, if a name is appended to the 'classes' attribute of the root document, this name is lost during the current version of the TitlePromoter transform. What I propose in the associated patch is to add more functionality to the Element class to handle generic attribute assignment and merging and then to call this instead of directly updating the attribute dictionary as done in the current code. This method has the ability to append rather than overwrite the basis attributes of an element as well as append any list elements in both the document and the section being merged in and replacing any attributes that are not both of list type with the values in the section node. This preserves the values in the document class list attributes as the user would expect. --- 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...> - 2024-08-30 12:08:39
|
- **status**: open --> open-remind - **Comment**: The rST syntax for internal [hyperlink targets](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#hyperlink-targets) applies a "name/label" to the following element. It can be used to name a figure element: ~~~ .. _figure-label: .. figure:: myfile.png :name: imagelabel Figure caption. ~~~ creates the HTML snippet: ~~~ <figure id="figure-label"> <img alt="myfile.png" id="imagelabel" src="myfile.png" /> <figcaption> <p>Figure caption.</p> </figcaption> </figure> ~~~ A "figname" directive option would provide an alternative way to name a figure element: -1 There should be one-- and preferably only one --obvious way to do it. +1 consistent with the "name" and "figclass" directive options. So, the jury is still out what is the better choice. Input welcome. --- **[feature-requests:#44] Add :figname: option to the figure directive** **Status:** open-remind **Group:** Default **Created:** Wed Mar 11, 2015 03:25 PM UTC by Jellby **Last Updated:** Wed Mar 11, 2015 03:25 PM UTC **Owner:** nobody As suggested in https://sourceforge.net/p/docutils/bugs/274/, I fill a feature request for a :figname: option to figure, so I can add a name to a figure and not to the image inside. --- 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...> - 2024-08-30 11:40:03
|
@aa-turner: Do the tests still fail on Windows? --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Thu Aug 15, 2024 08:51 PM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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: engelbert g. <eng...@gm...> - 2024-08-17 13:53:27
|
no objection On Fri, 16 Aug 2024 at 11:15, Guenter Milde via Docutils-develop < doc...@li...> wrote: > Dear Adam, dear Docutils developers, > > Commits [r9872], [r9873], and [r9874] added type hints for the > "readers", "parsers", and "writers" modules increasing their size by > 42, 70, and 112 lines respectively. > > > The reason is the provision of the exact output value for a set of specific > input vales via the `@overload` decorator for the auxiliary functions > `get_*_class()`. > > IMO, this is an overkill: the `@overload` is fine, if different types of > input values result in different types of output values, e.g, > > def foo(a: str) -> str > > def foo(a: binary) -> binary > > but not for individual values of the same type that return a class that is > a subclass of a well defined abstract base class (readers.Reader, > parsers.Parser, writers.Writer) and where the set of admissible values is > not known (any 3rd party component is found, too). > > My argument is, that the `get_*_class()` function is intended for use > when the component class is fetched at runtime from user configuration > (which means we only know that the return value conforms to the interface > of the abstract base class). > > In cases where a statical type checker knows the `reader_name`, > `parser_name`, `writer_name` (and this matters) there is no need to use > `get_*_class()` but the calling code may directly import the component > class. > > Unless there is a convincing use case, I vote for reversal of the change to > the `get_*_class()` functions. However, I'd like some feedback before > actually reverting. > > Günter > > > > > _______________________________________________ > Docutils-develop mailing list > Doc...@li... > https://lists.sourceforge.net/lists/listinfo/docutils-develop > > Please use "Reply All" to reply to the list. > |
From: Guenter M. <mi...@us...> - 2024-08-16 09:14:52
|
Dear Adam, dear Docutils developers, Commits [r9872], [r9873], and [r9874] added type hints for the "readers", "parsers", and "writers" modules increasing their size by 42, 70, and 112 lines respectively. The reason is the provision of the exact output value for a set of specific input vales via the `@overload` decorator for the auxiliary functions `get_*_class()`. IMO, this is an overkill: the `@overload` is fine, if different types of input values result in different types of output values, e.g, def foo(a: str) -> str def foo(a: binary) -> binary but not for individual values of the same type that return a class that is a subclass of a well defined abstract base class (readers.Reader, parsers.Parser, writers.Writer) and where the set of admissible values is not known (any 3rd party component is found, too). My argument is, that the `get_*_class()` function is intended for use when the component class is fetched at runtime from user configuration (which means we only know that the return value conforms to the interface of the abstract base class). In cases where a statical type checker knows the `reader_name`, `parser_name`, `writer_name` (and this matters) there is no need to use `get_*_class()` but the calling code may directly import the component class. Unless there is a convincing use case, I vote for reversal of the change to the `get_*_class()` functions. However, I'd like some feedback before actually reverting. Günter |
From: Günter M. <mi...@us...> - 2024-08-15 20:51:43
|
@aa-turner: Could you create a patch that just > Changes the default `root_prefix` to `''` (the empty string), and only applies the `root_prefix` behaviour when it is non-empty (i.e. a user has configured the setting) I agree that this is easier to explain (while the current implementation does not need a conditional). As the change is also backwards-compatible we can implement it without advance warning. --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Sun Aug 11, 2024 10:44 PM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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...> - 2024-08-15 14:13:27
|
> Aside from verbosity, I'm unsure of the argument to change this. Readabilty counts. > Verbosity can be managed with a type alias, This was my first idea. The best name for such a type alias would be "Node" (for any node in a document tree). The name was already take by a class documented as "Abstract base class of nodes in a document tree." So, instead [r9901] makes sure that all methods and attributes that are common to "Element" and "Text" are also defined for "Node": Node.children is now an empty tuple (as in Text). There is still no "Node.attributes". However, if a return value "rv" is hinted as "Element | Text" "rv.attributes" cannot be safely used either (as "Text.attributes" does not exist). To safequard against accidential use of a "Node" instance, "Node" can be based on "abc.ABC" and the abstact methods decorated with "abc.abstractmethod". See appended patch. Attachments: - [abstract-Node-class.patch](https://sourceforge.net/p/docutils/patches/_discuss/thread/1b42c5b086/6007/attachment/abstract-Node-class.patch) (6.6 kB; text/x-patch) --- **[patches:#210] Typing and `docutils.nodes.Node`** **Status:** open **Group:** None **Created:** Thu Aug 15, 2024 08:38 AM UTC by Adam Turner **Last Updated:** Thu Aug 15, 2024 08:39 AM UTC **Owner:** nobody Commit [r9901] by @milde changes instances of `Element | Text` to `Node`, and adds attributes to `Node`. I think that this is a not the best and the commit should be reverted before the impending 0.22 release, to allow for more discussion. As I noted in commit [r9813] which added type hints: ```text Add type hints to ``docutils.nodes`` A significant number of parameters and attributes are typed as expecting or yielding ``Element | Text`` rather than ``Node``, which is the more obvious choice. This union type is used because ``Node`` is de facto an abstract base class --- it should not be used or instantiated. Notably, ``Node.children`` is not defined, ``Node.attributes`` does not exist, etc. The two direct subclasses fill in many of these missing pieces, making static typing both more precise and easier. ``` ``Element`` and ``Text`` are different types, as `Text` can be treated as a string and `Element` means that we have a concrete node type with attributes and data. Conflating these as `Node` is unhelpful, and we shouldn't signal to users that a `Node` is expected anywhere, as whilst is is *de facto* an abstract base class, it can be instantiated and used at runtime, which should be heavily discouraged. Aside from verbosity, I'm unsure of the argument to change this. Verbosity can be managed with a type alias, as we had previously used (`ElementT`, though this should perhaps be named `ElementOrText`). A --- 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. |
From: Adam T. <aa-...@us...> - 2024-08-15 08:39:13
|
- Description has changed: Diff: ~~~~ --- old +++ new @@ -2,7 +2,7 @@ As I noted in commit [r9813] which added type hints: -``` +```text Add type hints to ``docutils.nodes`` A significant number of parameters and attributes are typed as ~~~~ --- **[patches:#210] Typing and `docutils.nodes.Node`** **Status:** open **Group:** None **Created:** Thu Aug 15, 2024 08:38 AM UTC by Adam Turner **Last Updated:** Thu Aug 15, 2024 08:38 AM UTC **Owner:** nobody Commit [r9901] by @milde changes instances of `Element | Text` to `Node`, and adds attributes to `Node`. I think that this is a not the best and the commit should be reverted before the impending 0.22 release, to allow for more discussion. As I noted in commit [r9813] which added type hints: ```text Add type hints to ``docutils.nodes`` A significant number of parameters and attributes are typed as expecting or yielding ``Element | Text`` rather than ``Node``, which is the more obvious choice. This union type is used because ``Node`` is de facto an abstract base class --- it should not be used or instantiated. Notably, ``Node.children`` is not defined, ``Node.attributes`` does not exist, etc. The two direct subclasses fill in many of these missing pieces, making static typing both more precise and easier. ``` ``Element`` and ``Text`` are different types, as `Text` can be treated as a string and `Element` means that we have a concrete node type with attributes and data. Conflating these as `Node` is unhelpful, and we shouldn't signal to users that a `Node` is expected anywhere, as whilst is is *de facto* an abstract base class, it can be instantiated and used at runtime, which should be heavily discouraged. Aside from verbosity, I'm unsure of the argument to change this. Verbosity can be managed with a type alias, as we had previously used (`ElementT`, though this should perhaps be named `ElementOrText`). A --- 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. |
From: Adam T. <aa-...@us...> - 2024-08-15 08:38:37
|
--- **[patches:#210] Typing and `docutils.nodes.Node`** **Status:** open **Group:** None **Created:** Thu Aug 15, 2024 08:38 AM UTC by Adam Turner **Last Updated:** Thu Aug 15, 2024 08:38 AM UTC **Owner:** nobody Commit [r9901] by @milde changes instances of `Element | Text` to `Node`, and adds attributes to `Node`. I think that this is a not the best and the commit should be reverted before the impending 0.22 release, to allow for more discussion. As I noted in commit [r9813] which added type hints: ``` Add type hints to ``docutils.nodes`` A significant number of parameters and attributes are typed as expecting or yielding ``Element | Text`` rather than ``Node``, which is the more obvious choice. This union type is used because ``Node`` is de facto an abstract base class --- it should not be used or instantiated. Notably, ``Node.children`` is not defined, ``Node.attributes`` does not exist, etc. The two direct subclasses fill in many of these missing pieces, making static typing both more precise and easier. ``` ``Element`` and ``Text`` are different types, as `Text` can be treated as a string and `Element` means that we have a concrete node type with attributes and data. Conflating these as `Node` is unhelpful, and we shouldn't signal to users that a `Node` is expected anywhere, as whilst is is *de facto* an abstract base class, it can be instantiated and used at runtime, which should be heavily discouraged. Aside from verbosity, I'm unsure of the argument to change this. Verbosity can be managed with a type alias, as we had previously used (`ElementT`, though this should perhaps be named `ElementOrText`). A --- 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. |
From: engelbert g. <gr...@us...> - 2024-08-15 08:20:35
|
- **status**: pending-remind --> open-fixed - **Comment**: applied the patch --- **[patches:#187] Rename .txt files to .rst** **Status:** open-fixed **Group:** None **Created:** Wed Jan 05, 2022 05:51 PM UTC by Adam Turner **Last Updated:** Fri Aug 09, 2024 09:35 AM UTC **Owner:** Adam Turner This change is in two parts -- the first commit does the rename and the second goes through and updates references to .txt files. All tests pass. The benefit of this change is primarily for people -- on user interfaces with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code mirrors, etc), the text is presented natively as reStructuredText, and editor features can assist with e.g. autocompletion. Docutils itself of course does not care which file extension is used. I have not renamed any of the include files or template files in `docutils.parsers` or `docutils.writers`, as they form part of the public API and would need a deprecation cycle (or aliasing in the parsing code) A Please see https://github.com/AA-Turner/docutils/pull/3 and https://github.com/AA-Turner/docutils/pull/3.patch for the commits and patch. --- 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. |
From: engelbert g. <gr...@us...> - 2024-08-13 12:32:03
|
infrastructure docutils-update.local should prefer .rst but falls back on .txt ./docs/user/Makefile.docutils-update has fixed filenames but is only one file On Sun, 11 Aug 2024 at 13:57, engelbert gruber < gr...@us...> wrote: > sandbox/infrastructure/docutils-update.local errors will pop up when > run , no problem to me > > On Fri, 9 Aug 2024 at 11:35, Günter Milde mi...@us... > wrote: > > We would need to adapt background scripts, too. I am unsure whether the > following changes correctly describe the behaviour after applying this > patch : > > --- a/sandbox/infrastructure/docutils-update.local+++ > b/sandbox/infrastructure/docutils-update.local@@ -14,10 +14,10 @@ # # > ATTENTION #-# Any .html document with a corresponding .txt file is > regenerated -# if the .txt has changed, but no new .html files will be > generated.+# Any .html document with a corresponding .rst file is > regenerated +# if the .rst has changed, but no new .html files will be > generated. #-# * Funny thing: sf hides README.txt files.+# * Funny thing: > sf hides README.rst files. # # ATTENTION > > I downloaded the patch set and tried to commit it to a local branch but > failed: > > milde@heinz:/usr/local/src/docutils-git-svn/docutils/docutils > git am -3 > /tmp/17.patch Applying: Rename all .txt files to .rstApplying: Update > references to .txt filesUsing index info to reconstruct a base tree...M > docutils/test/test_utils/test__init__.py.git/rebase-apply/patch:7937: > trailing whitespace.# Any .html document with a corresponding .rst file is > regenerated error: patch failed: docutils/docs/ref/rst/history.rst:1error: > docutils/docs/ref/rst/history.rst: patch does not applyerror: Did you hand > edit your patch?It does not apply to blobs recorded in its index.Patch > failed at 0002 Update references to .txt fileshint: Use 'git am > --show-current-patch=diff' to see the failed patchWhen you have resolved > this problem, run "git am --continue".If you prefer to skip this patch, run > "git am --skip" instead.To restore the original branch and stop patching, > run "git am --abort". > ------------------------------ > > > *[patches:#187] <https://sourceforge.net/p/docutils/patches/187/> > https://sourceforge.net/p/docutils/patches/187/ > <https://sourceforge.net/p/docutils/patches/187/> Rename .txt files to .rst* > > *Status:* pending-remind > *Group:* None > *Created:* Wed Jan 05, 2022 05:51 PM UTC by Adam Turner > *Last Updated:* Fri Aug 09, 2024 05:12 AM UTC > *Owner:* Adam Turner > > This change is in two parts -- the first commit does the rename and the > second goes through and updates references to .txt files. All tests pass. > > The benefit of this change is primarily for people -- on user interfaces > with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code > mirrors, etc), the text is presented natively as reStructuredText, and > editor features can assist with e.g. autocompletion. > > Docutils itself of course does not care which file extension is used. > > I have not renamed any of the include files or template files in > docutils.parsers or docutils.writers, as they form part of the public API > and would need a deprecation cycle (or aliasing in the parsing code) > > A > > Please see https://github.com/AA-Turner/docutils/pull/3 and > https://github.com/AA-Turner/docutils/pull/3.patch for the commits and > patch. > ------------------------------ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/docutils/patches/187/ > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > > ------------------------------ > > *[patches:#187] <https://sourceforge.net/p/docutils/patches/187/> Rename > .txt files to .rst* > > *Status:* pending-remind > *Group:* None > *Created:* Wed Jan 05, 2022 05:51 PM UTC by Adam Turner > *Last Updated:* Fri Aug 09, 2024 09:35 AM UTC > *Owner:* Adam Turner > > This change is in two parts -- the first commit does the rename and the > second goes through and updates references to .txt files. All tests pass. > > The benefit of this change is primarily for people -- on user interfaces > with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code > mirrors, etc), the text is presented natively as reStructuredText, and > editor features can assist with e.g. autocompletion. > > Docutils itself of course does not care which file extension is used. > > I have not renamed any of the include files or template files in > docutils.parsers or docutils.writers, as they form part of the public API > and would need a deprecation cycle (or aliasing in the parsing code) > > A > > Please see https://github.com/AA-Turner/docutils/pull/3 and > https://github.com/AA-Turner/docutils/pull/3.patch for the commits and > patch. > ------------------------------ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/docutils/patches/187/ > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > --- **[patches:#187] Rename .txt files to .rst** **Status:** pending-remind **Group:** None **Created:** Wed Jan 05, 2022 05:51 PM UTC by Adam Turner **Last Updated:** Fri Aug 09, 2024 09:35 AM UTC **Owner:** Adam Turner This change is in two parts -- the first commit does the rename and the second goes through and updates references to .txt files. All tests pass. The benefit of this change is primarily for people -- on user interfaces with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code mirrors, etc), the text is presented natively as reStructuredText, and editor features can assist with e.g. autocompletion. Docutils itself of course does not care which file extension is used. I have not renamed any of the include files or template files in `docutils.parsers` or `docutils.writers`, as they form part of the public API and would need a deprecation cycle (or aliasing in the parsing code) A Please see https://github.com/AA-Turner/docutils/pull/3 and https://github.com/AA-Turner/docutils/pull/3.patch for the commits and patch. --- 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. |
From: engelbert g. <gr...@us...> - 2024-08-13 11:12:54
|
i could apply the rename this week ... nag me On Tue, 13 Aug 2024 at 12:42, engelbert gruber < gr...@us...> wrote: > infrastructure docutils-update.local should prefer .rst but falls back on > .txt > > ./docs/user/Makefile.docutils-update > > has fixed filenames but is only one file > > > > On Sun, 11 Aug 2024 at 13:57, engelbert gruber < > gr...@us...> wrote: > >> sandbox/infrastructure/docutils-update.local errors will pop up when >> run , no problem to me >> >> On Fri, 9 Aug 2024 at 11:35, Günter Milde mi...@us... >> wrote: >> >> We would need to adapt background scripts, too. I am unsure whether the >> following changes correctly describe the behaviour after applying this >> patch : >> >> --- a/sandbox/infrastructure/docutils-update.local+++ >> b/sandbox/infrastructure/docutils-update.local@@ -14,10 +14,10 @@ # # >> ATTENTION #-# Any .html document with a corresponding .txt file is >> regenerated -# if the .txt has changed, but no new .html files will be >> generated.+# Any .html document with a corresponding .rst file is >> regenerated +# if the .rst has changed, but no new .html files will be >> generated. #-# * Funny thing: sf hides README.txt files.+# * Funny thing: >> sf hides README.rst files. # # ATTENTION >> >> I downloaded the patch set and tried to commit it to a local branch but >> failed: >> >> milde@heinz:/usr/local/src/docutils-git-svn/docutils/docutils > git am >> -3 /tmp/17.patch Applying: Rename all .txt files to .rstApplying: Update >> references to .txt filesUsing index info to reconstruct a base tree...M >> docutils/test/test_utils/test__init__.py.git/rebase-apply/patch:7937: >> trailing whitespace.# Any .html document with a corresponding .rst file is >> regenerated error: patch failed: docutils/docs/ref/rst/history.rst:1error: >> docutils/docs/ref/rst/history.rst: patch does not applyerror: Did you hand >> edit your patch?It does not apply to blobs recorded in its index.Patch >> failed at 0002 Update references to .txt fileshint: Use 'git am >> --show-current-patch=diff' to see the failed patchWhen you have resolved >> this problem, run "git am --continue".If you prefer to skip this patch, run >> "git am --skip" instead.To restore the original branch and stop patching, >> run "git am --abort". >> ------------------------------ >> >> >> *[patches:#187] <https://sourceforge.net/p/docutils/patches/187/> >> https://sourceforge.net/p/docutils/patches/187/ >> <https://sourceforge.net/p/docutils/patches/187/> Rename .txt files to .rst* >> >> *Status:* pending-remind >> *Group:* None >> *Created:* Wed Jan 05, 2022 05:51 PM UTC by Adam Turner >> *Last Updated:* Fri Aug 09, 2024 05:12 AM UTC >> *Owner:* Adam Turner >> >> This change is in two parts -- the first commit does the rename and the >> second goes through and updates references to .txt files. All tests pass. >> >> The benefit of this change is primarily for people -- on user interfaces >> with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code >> mirrors, etc), the text is presented natively as reStructuredText, and >> editor features can assist with e.g. autocompletion. >> >> Docutils itself of course does not care which file extension is used. >> >> I have not renamed any of the include files or template files in >> docutils.parsers or docutils.writers, as they form part of the public API >> and would need a deprecation cycle (or aliasing in the parsing code) >> >> A >> >> Please see https://github.com/AA-Turner/docutils/pull/3 and >> https://github.com/AA-Turner/docutils/pull/3.patch for the commits and >> patch. >> ------------------------------ >> >> Sent from sourceforge.net because you indicated interest in >> https://sourceforge.net/p/docutils/patches/187/ >> >> To unsubscribe from further messages, please visit >> https://sourceforge.net/auth/subscriptions/ >> >> ------------------------------ >> >> *[patches:#187] <https://sourceforge.net/p/docutils/patches/187/> Rename >> .txt files to .rst* >> >> *Status:* pending-remind >> *Group:* None >> *Created:* Wed Jan 05, 2022 05:51 PM UTC by Adam Turner >> *Last Updated:* Fri Aug 09, 2024 09:35 AM UTC >> *Owner:* Adam Turner >> >> This change is in two parts -- the first commit does the rename and the >> second goes through and updates references to .txt files. All tests pass. >> >> The benefit of this change is primarily for people -- on user interfaces >> with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code >> mirrors, etc), the text is presented natively as reStructuredText, and >> editor features can assist with e.g. autocompletion. >> >> Docutils itself of course does not care which file extension is used. >> >> I have not renamed any of the include files or template files in >> docutils.parsers or docutils.writers, as they form part of the public >> API and would need a deprecation cycle (or aliasing in the parsing code) >> >> A >> >> Please see https://github.com/AA-Turner/docutils/pull/3 and >> https://github.com/AA-Turner/docutils/pull/3.patch for the commits and >> patch. >> ------------------------------ >> >> Sent from sourceforge.net because you indicated interest in >> https://sourceforge.net/p/docutils/patches/187/ >> >> To unsubscribe from further messages, please visit >> https://sourceforge.net/auth/subscriptions/ >> > --- **[patches:#187] Rename .txt files to .rst** **Status:** pending-remind **Group:** None **Created:** Wed Jan 05, 2022 05:51 PM UTC by Adam Turner **Last Updated:** Fri Aug 09, 2024 09:35 AM UTC **Owner:** Adam Turner This change is in two parts -- the first commit does the rename and the second goes through and updates references to .txt files. All tests pass. The benefit of this change is primarily for people -- on user interfaces with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code mirrors, etc), the text is presented natively as reStructuredText, and editor features can assist with e.g. autocompletion. Docutils itself of course does not care which file extension is used. I have not renamed any of the include files or template files in `docutils.parsers` or `docutils.writers`, as they form part of the public API and would need a deprecation cycle (or aliasing in the parsing code) A Please see https://github.com/AA-Turner/docutils/pull/3 and https://github.com/AA-Turner/docutils/pull/3.patch for the commits and patch. --- 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. |
From: engelbert g. <gr...@us...> - 2024-08-13 11:02:50
|
nut i would only apply on svn ... might be not what's wanted On Tue, 13 Aug 2024 at 12:43, engelbert gruber < gr...@us...> wrote: > i could apply the rename this week ... nag me > > On Tue, 13 Aug 2024 at 12:42, engelbert gruber < > gr...@us...> wrote: > >> infrastructure docutils-update.local should prefer .rst but falls back on >> .txt >> >> ./docs/user/Makefile.docutils-update >> >> has fixed filenames but is only one file >> >> >> >> On Sun, 11 Aug 2024 at 13:57, engelbert gruber < >> gr...@us...> wrote: >> >>> sandbox/infrastructure/docutils-update.local errors will pop up when >>> run , no problem to me >>> >>> On Fri, 9 Aug 2024 at 11:35, Günter Milde mi...@us... >>> wrote: >>> >>> We would need to adapt background scripts, too. I am unsure whether the >>> following changes correctly describe the behaviour after applying this >>> patch : >>> >>> --- a/sandbox/infrastructure/docutils-update.local+++ >>> b/sandbox/infrastructure/docutils-update.local@@ -14,10 +14,10 @@ # # >>> ATTENTION #-# Any .html document with a corresponding .txt file is >>> regenerated -# if the .txt has changed, but no new .html files will be >>> generated.+# Any .html document with a corresponding .rst file is >>> regenerated +# if the .rst has changed, but no new .html files will be >>> generated. #-# * Funny thing: sf hides README.txt files.+# * Funny thing: >>> sf hides README.rst files. # # ATTENTION >>> >>> I downloaded the patch set and tried to commit it to a local branch but >>> failed: >>> >>> milde@heinz:/usr/local/src/docutils-git-svn/docutils/docutils > git am >>> -3 /tmp/17.patch Applying: Rename all .txt files to .rstApplying: Update >>> references to .txt filesUsing index info to reconstruct a base tree...M >>> docutils/test/test_utils/test__init__.py.git/rebase-apply/patch:7937: >>> trailing whitespace.# Any .html document with a corresponding .rst file is >>> regenerated error: patch failed: docutils/docs/ref/rst/history.rst:1error: >>> docutils/docs/ref/rst/history.rst: patch does not applyerror: Did you hand >>> edit your patch?It does not apply to blobs recorded in its index.Patch >>> failed at 0002 Update references to .txt fileshint: Use 'git am >>> --show-current-patch=diff' to see the failed patchWhen you have resolved >>> this problem, run "git am --continue".If you prefer to skip this patch, run >>> "git am --skip" instead.To restore the original branch and stop patching, >>> run "git am --abort". >>> ------------------------------ >>> >>> >>> *[patches:#187] <https://sourceforge.net/p/docutils/patches/187/> >>> https://sourceforge.net/p/docutils/patches/187/ >>> <https://sourceforge.net/p/docutils/patches/187/> Rename .txt files to .rst* >>> >>> *Status:* pending-remind >>> *Group:* None >>> *Created:* Wed Jan 05, 2022 05:51 PM UTC by Adam Turner >>> *Last Updated:* Fri Aug 09, 2024 05:12 AM UTC >>> *Owner:* Adam Turner >>> >>> This change is in two parts -- the first commit does the rename and the >>> second goes through and updates references to .txt files. All tests pass. >>> >>> The benefit of this change is primarily for people -- on user interfaces >>> with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, >>> code >>> mirrors, etc), the text is presented natively as reStructuredText, and >>> editor features can assist with e.g. autocompletion. >>> >>> Docutils itself of course does not care which file extension is used. >>> >>> I have not renamed any of the include files or template files in >>> docutils.parsers or docutils.writers, as they form part of the public API >>> and would need a deprecation cycle (or aliasing in the parsing code) >>> >>> A >>> >>> Please see https://github.com/AA-Turner/docutils/pull/3 and >>> https://github.com/AA-Turner/docutils/pull/3.patch for the commits and >>> patch. >>> ------------------------------ >>> >>> Sent from sourceforge.net because you indicated interest in >>> https://sourceforge.net/p/docutils/patches/187/ >>> >>> To unsubscribe from further messages, please visit >>> https://sourceforge.net/auth/subscriptions/ >>> >>> ------------------------------ >>> >>> *[patches:#187] <https://sourceforge.net/p/docutils/patches/187/> Rename >>> .txt files to .rst* >>> >>> *Status:* pending-remind >>> *Group:* None >>> *Created:* Wed Jan 05, 2022 05:51 PM UTC by Adam Turner >>> *Last Updated:* Fri Aug 09, 2024 09:35 AM UTC >>> *Owner:* Adam Turner >>> >>> This change is in two parts -- the first commit does the rename and the >>> second goes through and updates references to .txt files. All tests pass. >>> >>> The benefit of this change is primarily for people -- on user interfaces >>> with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code >>> mirrors, etc), the text is presented natively as reStructuredText, and >>> editor features can assist with e.g. autocompletion. >>> >>> Docutils itself of course does not care which file extension is used. >>> >>> I have not renamed any of the include files or template files in >>> docutils.parsers or docutils.writers, as they form part of the public >>> API and would need a deprecation cycle (or aliasing in the parsing code) >>> >>> A >>> >>> Please see https://github.com/AA-Turner/docutils/pull/3 and >>> https://github.com/AA-Turner/docutils/pull/3.patch for the commits and >>> patch. >>> ------------------------------ >>> >>> Sent from sourceforge.net because you indicated interest in >>> https://sourceforge.net/p/docutils/patches/187/ >>> >>> To unsubscribe from further messages, please visit >>> https://sourceforge.net/auth/subscriptions/ >>> >> --- **[patches:#187] Rename .txt files to .rst** **Status:** pending-remind **Group:** None **Created:** Wed Jan 05, 2022 05:51 PM UTC by Adam Turner **Last Updated:** Fri Aug 09, 2024 09:35 AM UTC **Owner:** Adam Turner This change is in two parts -- the first commit does the rename and the second goes through and updates references to .txt files. All tests pass. The benefit of this change is primarily for people -- on user interfaces with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code mirrors, etc), the text is presented natively as reStructuredText, and editor features can assist with e.g. autocompletion. Docutils itself of course does not care which file extension is used. I have not renamed any of the include files or template files in `docutils.parsers` or `docutils.writers`, as they form part of the public API and would need a deprecation cycle (or aliasing in the parsing code) A Please see https://github.com/AA-Turner/docutils/pull/3 and https://github.com/AA-Turner/docutils/pull/3.patch for the commits and patch. --- 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. |
From: Günter M. <mi...@us...> - 2024-08-11 22:44:34
|
> The second commit in the patch goes further, by rejecting absolute paths when used in relative references. This is optional, but as I argue above I think allowing absolute paths in relative references leads to surprising behaviour the resolution is easy if you want to keep using absolute paths (just use file:///). Using file does not work if you want to generate HTML that should be served via https and * create two output versions with/without embedding images from the same source, or * read the image size from the file but not embed the image: ~~~ .. image:: /pictures/parrot.jpg :scale: 100 ~~~ If the http server looks for files in the dir "/public/wwwfiles/", say, you can set this dir as "root-prefix". --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Sun Aug 11, 2024 07:33 AM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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: engelbert g. <gr...@us...> - 2024-08-11 11:57:49
|
sandbox/infrastructure/docutils-update.local errors will pop up when run , no problem to me On Fri, 9 Aug 2024 at 11:35, Günter Milde <mi...@us...> wrote: > We would need to adapt background scripts, too. I am unsure whether the > following changes correctly describe the behaviour after applying this > patch : > > --- a/sandbox/infrastructure/docutils-update.local+++ b/sandbox/infrastructure/docutils-update.local@@ -14,10 +14,10 @@ # # ATTENTION #-# Any .html document with a corresponding .txt file is regenerated -# if the .txt has changed, but no new .html files will be generated.+# Any .html document with a corresponding .rst file is regenerated +# if the .rst has changed, but no new .html files will be generated. #-# * Funny thing: sf hides README.txt files.+# * Funny thing: sf hides README.rst files. # # ATTENTION > > I downloaded the patch set and tried to commit it to a local branch but > failed: > > milde@heinz:/usr/local/src/docutils-git-svn/docutils/docutils > git am -3 /tmp/17.patch Applying: Rename all .txt files to .rstApplying: Update references to .txt filesUsing index info to reconstruct a base tree...M docutils/test/test_utils/test__init__.py.git/rebase-apply/patch:7937: trailing whitespace.# Any .html document with a corresponding .rst file is regenerated error: patch failed: docutils/docs/ref/rst/history.rst:1error: docutils/docs/ref/rst/history.rst: patch does not applyerror: Did you hand edit your patch?It does not apply to blobs recorded in its index.Patch failed at 0002 Update references to .txt fileshint: Use 'git am --show-current-patch=diff' to see the failed patchWhen you have resolved this problem, run "git am --continue".If you prefer to skip this patch, run "git am --skip" instead.To restore the original branch and stop patching, run "git am --abort". > > ------------------------------ > > *[patches:#187] <https://sourceforge.net/p/docutils/patches/187/> Rename > .txt files to .rst* > > *Status:* pending-remind > *Group:* None > *Created:* Wed Jan 05, 2022 05:51 PM UTC by Adam Turner > *Last Updated:* Fri Aug 09, 2024 05:12 AM UTC > *Owner:* Adam Turner > > This change is in two parts -- the first commit does the rename and the > second goes through and updates references to .txt files. All tests pass. > > The benefit of this change is primarily for people -- on user interfaces > with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code > mirrors, etc), the text is presented natively as reStructuredText, and > editor features can assist with e.g. autocompletion. > > Docutils itself of course does not care which file extension is used. > > I have not renamed any of the include files or template files in > docutils.parsers or docutils.writers, as they form part of the public API > and would need a deprecation cycle (or aliasing in the parsing code) > > A > > Please see https://github.com/AA-Turner/docutils/pull/3 and > https://github.com/AA-Turner/docutils/pull/3.patch for the commits and > patch. > ------------------------------ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/docutils/patches/187/ > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > --- **[patches:#187] Rename .txt files to .rst** **Status:** pending-remind **Group:** None **Created:** Wed Jan 05, 2022 05:51 PM UTC by Adam Turner **Last Updated:** Fri Aug 09, 2024 09:35 AM UTC **Owner:** Adam Turner This change is in two parts -- the first commit does the rename and the second goes through and updates references to .txt files. All tests pass. The benefit of this change is primarily for people -- on user interfaces with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code mirrors, etc), the text is presented natively as reStructuredText, and editor features can assist with e.g. autocompletion. Docutils itself of course does not care which file extension is used. I have not renamed any of the include files or template files in `docutils.parsers` or `docutils.writers`, as they form part of the public API and would need a deprecation cycle (or aliasing in the parsing code) A Please see https://github.com/AA-Turner/docutils/pull/3 and https://github.com/AA-Turner/docutils/pull/3.patch for the commits and patch. --- 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. |
From: Günter M. <mi...@us...> - 2024-08-11 07:33:25
|
> I think we should use Path.as_uri() instead of .as_posix(). Done in [r9882]. --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Sat Aug 10, 2024 11:04 PM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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...> - 2024-08-10 23:04:26
|
Another example why we should make it clear that the image argument is an "URI reference": ~~~ .. image:: My Documents/first drawing.png ~~~ is parsed to ~~~ .. image:: My Documents/first drawing.png ~~~ because [spaces are dropped from link blocks and image-URIs](https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html#uri-context) to allow easy breaking of long URIs over several lines. This behaviour is surprising when you consider an image attribute without scheme a path. --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Sat Aug 10, 2024 02:48 PM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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...> - 2024-08-10 14:48:42
|
Your analysis with "the `uri_parts.scheme not in ('', 'file')` check" beeing "the root cause" of the test failure is correct. This check was introduced in [r9501] "Refactor "_html_base" writer." However, even before (since introduction of image embedding in 0.18), the drive part was split from the path. To verify this, try `PS> echo ".. image:: S:/Development/docutils/docutils/test/data/circle.svg" | python rst2html5.py --link-stylesheet --image-loading embed` from a directory in a different drive. BTW: both, the introduction of the :loading: directive option and of direct embedding of SVG images did not change path handling (you should get the same behaviour with a PNG or JPG image). --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Sat Aug 10, 2024 02:09 PM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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...> - 2024-08-10 14:09:33
|
> the second is needlessly restrictive and hard to explain. Suppose a user has a directive ``.. image:: /media/circle.svg``. By default this will load the file under `/media/circle.svg`, as the user might expect if they think they are using filesystem paths, and don't realise the nuances of URI references. At some later date, this user sets `root_prefix` to `/home/user/project/`. The image directive will stop working, as it now looks for a file under `/home/user/project/media/circle.svg`. I think this behaviour is hard to explain and quite surprising. I have a proposed fix at https://github.com/AA-Turner/docutils/pull/18 (https://github.com/AA-Turner/docutils/pull/18.patch). This does the following: * Adds a helper function to convert image URIs to paths * Updates all writers (HTML, LaTeX, and ODF/ODT) that support images to use this helper for consistent behaviour * Correctly convert `file:///` URIs to filesystem paths (using Python 3.13's [Path.from_uri()](https://docs.python.org/3.13/library/pathlib.html#pathlib.Path.from_uri) where possible). * Validate that `file:` URIs are absolute paths * Correctly convert relative references to filesystem paths * Changes the default `root_prefix` to `''` (the empty string), and only applies the `root_prefix` behaviour when it is non-empty (i.e. a user has configured the setting) The second commit in the patch goes further, by rejecting absolute paths when used in relative references. This is optional, but as I argue above I think allowing absolute paths in relative references leads to surprising behaviour, and the resolution is easy if you want to keep using absolute paths (just use `file:///`). I think this would be a straightforward end-state to explain to users: either the argument to `.. image::` (and `.. figure::`) is a URI or it is a relative filesystem path. A --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Sat Aug 10, 2024 08:29 AM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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...> - 2024-08-10 08:29:24
|
> I think we have two options. > (1) support absolute paths on every platform, document as such. > (2) make absolute paths return an error on Linux. (3) support URI-references: URI | absolute (POSIX) path | relative (POSIX) path >The first restores backwards compatibility, the second is needlessly restrictive and hard to explain. The third is consistent with what we document. It is also in line with "root-prefix" only being used if a path starts with "/". The different handling of Windows system paths is due to the syntax definition of URIs where the "path" part is represented by a POSIX path. --- > I think we should use Path.as_uri() instead of .as_posix(). I prepared a patch. BTW: the docs for .as_posix() write: ~~~ >>> p = PureWindowsPath('c:/Windows') >>> p.as_uri() 'file:///c:/Windows' ~~~ Then `/c:/Windows` may be usable as both, absolute file system path under Windows and "absolute-path reference" [1](https://www.rfc-editor.org/rfc/rfc3986.html#section-4.2) in a URI-reference like: ~~~ .. image:: /E:/DCIM/parrot.jpg ~~~ --- **[bugs:#493] Test failure on Windows with embedded images** **Status:** open **Created:** Wed Aug 07, 2024 02:25 AM UTC by Adam Turner **Last Updated:** Fri Aug 09, 2024 09:55 PM UTC **Owner:** nobody xref [r9785], [r9853], [r9855] Dear @milde, Thank you for the fix to my recent patch. It seems neither my patch nor the fix addressed the root cause of the test failures, as tests have resumed failing on Windows. I believe the following demonstrates the problem: ```pycon >>> import sys; print(sys.platform) win32 >>> import urllib.parse, urllib.request >>> urllib.request.url2pathname('test/data/circle-broken.svg') 'test\\data\\circle-broken.svg' >>> urllib.parse.unquote('test/data/circle-broken.svg') 'test/data/circle-broken.svg' ``` Currently, we use `imagepath = urllib.request.url2pathname(uri_parts.path)`, which converts path separators to their platform-native format. On UNIX, `url2pathname` simply calls `unquote`, but on Windows it handles UNC paths (``\\host\path\``) and escaped drive letters (``///C|/users/``). I don't know what led to using `url2pathname()`, as it is quite specialised (the docstring notes "not recommended for general use"). Is it possible to use the simpler `unquote()` here? For local file paths (e.g. without a ``file:///`` scheme), should we even be using URI parsing? Perhaps we should use proper path handling if there is no URI scheme (i.e. the user has provided a file-path). A --- 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. |