Re: [Docutils-develop] widths argument for tables

[David Goodger <goodger@py...>]

On Wed, Mar 4, 2015 at 6:18 AM, Guenter Milde <milde@...> wrote:
> On 2015-02-25, Brecht Machiels wrote:
>
>> Not that you'll also need the changes in [patch 125], which has not
>> been accepted yet
>
> Up to now, the default behaviour of the table directive/construct is not
> changed in the output, as no writer implements the "auto" option.
>
> Patches 123 ... 125 would change this, however:
>
> Chanching the default behaviour is problematic for existing documents --
> Docutils has a strong tratidion of backwards compatibility whenever possible.
>
> A new default behaviour should only be introduced after careful
> consideration, consensus between the main developers, and an advance
> warning to the users. (See News.txt for examples.)
>
> I see a point in arguing for "auto" as sensible default:
>
>   For all tables (so also simple/grid tables without table directive),
>   :widths: is assumed to be 'auto' when the :widths: option is not
>   specified, so that :widths: behavior is uniform across the table
>   directives. I believe the choice for ":widths: auto" is obvious for csv
>   and list tables. For simple/grid tables, this is debatable, but I'd go
>   for consistency across the different table formats.
>
> However, I would not make it the default *now*.
>
> Instead, leave the default behaviour as-is, road-test the new options,
> announce a future change and eventually change the default in a later
> release.

+1

Perhaps add an --auto-table-column-widths option/setting to modify the
default, for those who do want it now.

> One argument for "auto" as opt-in (instead of default) is the behaviour
> of LaTeX: in LaTeX, tables have auto-sized columns by default, however
> without line-wrapping. Therefore, the current Docutils' latex2e writer
> explicitely defines fixed-width columns.
>   The "auto" setting would offer a means to get the often useful but
> not always usable LaTeX default columns. However, changes to existing
> documents would be substantial.
>
> https://sourceforge.net/p/docutils/patches/123/
>
> How about:
>
> ``widths`` : "auto", "grid" or a list of integers
>     This option controls the relative size of the columns.
>
>     A comma- or space-separated list of integers specifies the relative
>     column widths.
>
>     "grid" sizes the columns according to the relative character-widths
>     of the columns in the reStructuredText source.
>
>     For "auto", the columns are automatically sized based on their
>     contents by the backend.
>     If the output format or writer does not support auto-sizing columns,
>     the "grid" behaviour is used.

Is this feasible? If "auto" was chosen there is no "grid"-style data
in the doctree by the time it arrives at the Writer. If this is
necessary, we'll have to store that info in secondary attributes.

>     The current default is "grid". This may change in a later release to
>     "auto".

Otherwise, looks good.

> https://sourceforge.net/p/docutils/patches/125/
>
> Before applying this patch, I' want to see example output
> (a test case in docutils/test/test_writers/test_html4css1_misc.py, say).

(FYI to whoever does this:) This can be done by applying the patch
locally, adding a test with ":widths: auto", running the tests,
verifying the results (should be no change in non-auto-widths tables),
and copying the new test output to the corresponding expected output
file.

> Also, the default value issue must be solved first.
>
> Günter

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

[Docutils-develop] widths argument for tables

[Guenter Milde <milde@us...>]

On 2015-02-25, Brecht Machiels wrote:

> Not that you'll also need the changes in [patch 125], which has not
> been accepted yet

Up to now, the default behaviour of the table directive/construct is not
changed in the output, as no writer implements the "auto" option.

Patches 123 ... 125 would change this, however:

Chanching the default behaviour is problematic for existing documents --
Docutils has a strong tratidion of backwards compatibility whenever possible.

A new default behaviour should only be introduced after careful
consideration, consensus between the main developers, and an advance
warning to the users. (See News.txt for examples.)

I see a point in arguing for "auto" as sensible default:

  For all tables (so also simple/grid tables without table directive),
  :widths: is assumed to be 'auto' when the :widths: option is not
  specified, so that :widths: behavior is uniform across the table
  directives. I believe the choice for ":widths: auto" is obvious for csv
  and list tables. For simple/grid tables, this is debatable, but I'd go
  for consistency across the different table formats.

However, I would not make it the default *now*. 

Instead, leave the default behaviour as-is, road-test the new options,
announce a future change and eventually change the default in a later
release.

One argument for "auto" as opt-in (instead of default) is the behaviour
of LaTeX: in LaTeX, tables have auto-sized columns by default, however
without line-wrapping. Therefore, the current Docutils' latex2e writer
explicitely defines fixed-width columns. 
  The "auto" setting would offer a means to get the often useful but
not always usable LaTeX default columns. However, changes to existing
documents would be substantial.

https://sourceforge.net/p/docutils/patches/123/

How about:

``widths`` : "auto", "grid" or a list of integers
    This option controls the relative size of the columns.  
    
    A comma- or space-separated list of integers specifies the relative
    column widths.

    "grid" sizes the columns according to the relative character-widths
    of the columns in the reStructuredText source.
        
    For "auto", the columns are automatically sized based on their
    contents by the backend. 
    If the output format or writer does not support auto-sizing columns,
    the "grid" behaviour is used.
    
    The current default is "grid". This may change in a later release to
    "auto".

https://sourceforge.net/p/docutils/patches/125/

Before applying this patch, I' want to see example output
(a test case in docutils/test/test_writers/test_html4css1_misc.py, say).

Also, the default value issue must be solved first.

Günter

[Docutils-develop] [docutils:bugs] #273 wrong hyphenation in latex documents with rst2latex

[Günter Milde <milde@us...>]

Re: [Docutils-develop] indented class directives

[Jeffrey C. Jacobs <darklord@ti...>]

On Mon, Mar 2, 2015 at 11:17 AM,
<docutils-develop-request@...> wrote:
> Date: Wed, 25 Feb 2015 15:16:44 -0600
> From: David Goodger <goodger@...>
> Subject: Re: [Docutils-develop] indented class directives
> To: Guenter Milde <milde@...>
> Cc: Docutils Developers <docutils-develop@...>
> Message-ID:
>         <CABiJP=KK3RF7AwTstqjV42=FaicgS3zuo=0Yodge5wkQrfr0GA@...>
> Content-Type: text/plain; charset=UTF-8
>
> In addition, long ago I had an idea to modify the "class" directive
> with a :parent: or :container: option, to assign the class to the
> element containing the directive (the parent element). This option
> could also take an argument, the element type for assignment, so a
> class could be assigned to an arbitrary ancestor of the directive.

+1

[...]
>
> See http://docutils.sourceforge.net/docs/dev/todo.html#misc-class &
> http://article.gmane.org/gmane.text.docutils.devel/3165
>
> I never finished implementing this. Any takers?

Well, not that I wish per say to hang my hat on this, but since it may
yield a new solution to
https://sourceforge.net/p/docutils/feature-requests/18/ I'm a bit more
inclined to focus on this than the bigger nesting project.  That said,
however, as with any modification, I'm rather busy with other things
at the moment so please don't wait for me to finish it and so anyone
feel free to take it on but if I do find some time, I'll look into
this.

Jeffrey.

[Docutils-develop] [docutils:bugs] #273 wrong hyphenation in latex documents with rst2latex

[Mikolaj <mikmach@us...>]

[Docutils-develop] [docutils:bugs] #272 get_parser_class problems loading parsers from other modules

[Günter Milde <milde@us...>]

[Docutils-develop] [docutils:bugs] #272 get_parser_class problems loading parsers from other modules

[Matthew Woehlke <mw_triad@us...>]

[Docutils-develop] Development on branches (was: Re: Docutils-develop Digest, Vol 92, Issue 6)

[Stefan Merten <stefan@me...>]

Hi Jeffrey and all!

Last week (8 days ago) Jeffrey C Jacobs wrote:
> What I'm more bully about is my +3 on being able to contribute
> change-sets, not just diffs.  As a developer, I feel my work is
> trivialized if my contribution, that I may have worked on for a month,
> is trivialized to just one, single, monolithic diff.  I much prefer
> the work model as a branch, that makes changes over time, and then
> when I'm ready for code review I can provide the diff but my
> change-set would be public and thus the process at *how* I created the
> patch is also exposed.  This, IMHO, is what should become part of
> trunk, not just the one-time, one-page patch.

+2. Funny enough that the git community always emphasizes that this is
*not* the way things should be in git (though this might be possible
in this jungle of hashes...).

> Of course, there's also the issue of off-line software development
> which was a problem of the '00s but really, with all this modern
> connectivity it's less an issue.  Nice to have but not critical.

With SVN it is possible to have at least diffs to the last version
even in offline mode. If you are not traveling too long this should
suffice for some work.

> What
> I used to do is dump my entire SVN repository and load it into my
> remote laptop then dump the change-set and load it into my main
> server.

I rsync my personal repositories back and forth from my laptop to my
desktop. I'm either at home or on the road so this perfectly works for
me. I wrote that small script rsyncing my stuff many, many years ago
and it still works perfect...

> a) cp [branch] trunk to its own folder in sandbox, develop as normal,
> merging in trunk regularly, test-driven, etc.

BTW: That was possible back in the old CVS times. Then I developed
`lcvs` which has this feature (`lcvs Join`).

Apart from that: As is normal for a mature project commits on trunk
are rare so merging in latest changes should not be too much pain.

> Consider though the DVCS use-case:
> 
> c) User pulls the latest docutils, branches, does multiple checkins,
> test-driven development, occasional fetch-rebase operations to bring
> in the latest master, and then posts the branch to the ticket as ready
> for merging back to master.  No concerns about reintegration, or
> potential .mergeinfo corruption.  Simple, succinct, and preserving
> change-sets.

Well there *is* `git svn` (see
https://www.kernel.org/pub/software/scm/git/docs/git-svn.html).

Frankly: For all those people who argue so strong for git: Don't they
know their own tool? Well, I just looked at the man page but that
sounds as you could do your "hidden branching" Jeffrey and I dislike
using `git svn`. So they could have it their way while the core
docutils developers can stay with SVN.


						Grüße

						Stefan

Re: [Docutils-develop] html4css2 writer

[David Goodger <goodger@py...>]

On Sun, Feb 22, 2015 at 4:02 PM, Guenter Milde <milde@...> wrote:
> On 2015-02-19, David Goodger wrote:
>> This Writer subclasses the html4css1 Writer. Perhaps it would be wise
>> to add a warning to the html4css1 Writer's module about the
>> relationship.
>
> I propose to create a common parent-module "writers/html", let both
> inherit from there and add specific methods/data.

Unless this common parent module is itself a fully functional writer,
please make it unambiguously an abstract base class. Make the class
raise a NotImplementedError if instantiated directly, and give the
module a name like "_base_html".

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

[Docutils-develop] [docutils:bugs] #252 <tt> is obsolete in HTML5

[Günter Milde <milde@us...>]

[Docutils-develop] [docutils:bugs] #266 Creating labels (hyperlink targets) in description items

[Günter Milde <milde@us...>]

[Docutils-develop] [docutils:bugs] #266 Creating labels (hyperlink targets) in description items

[Günter Milde <milde@us...>]

Re: [Docutils-develop] indented class directives

[Guenter Milde <milde@us...>]

Dear David,

thanks for the fast response.

On 2015-02-25, David Goodger wrote:
> On Wed, Feb 25, 2015 at 11:53 AM, Guenter Milde <milde@...> wrote:
>> Dear David, dear Docutils developers,

>> trying to tackle bug 266 http://sourceforge.net/p/docutils/bugs/266/
>> I came across an interesting feature of the class directive:

>> The rST specs say:

>>   The "class" directive sets the "classes" attribute value on its content
>>   or on the first immediately following non-comment element.

>>   -- http://docutils.sourceforge.net/docs/ref/rst/directives.html#id14

>> This is also true, if the class directive is "nested" at the end of an
>> indented text block.

...

> This is absolutely intentional.

Then, the documentation should reflect this.

...

>> However, it is non-intuitive, as "normally", indented blocks signify
>> content that belongs together.

> Non-intuitive if you think it through too logically/hierarchically.
> Let your mind go free, flatten your notion of a document, and it makes
> perfect sense.

However, it is not intuitive to have to work with both concepts, a
hierarchical document structure (remember, that you are not allowed to
skip section levels) as well as a flat document model at the same time.

The documentation at all places stresses the hierarchical document model
"document tree". Therefore, it is important to be explicit, whenever
there is an intended deviation from this hierarchical approach.

> Also, it's damn useful.

Like many hacks (practicality beats purity).

...

>> The HTML writer currently ignores the class values of definition list items,
>> as there is no matching HTML element but only <dt> and <dd>.

> I'd consider that a bug of the HTML writer.

Given the above clarification, I agree.
(There would not be any need for code to pass class options on, if there
were no "official" means to specify them in the first place.)



>> The question now is:

>> How to proceed from the current situation:

>> a) document the current behaviour with an example in directives.txt?

> Yes. Improved documentation is always good.

>> b) change the behaviour: ignore and warn or throw an error, if a "class"
>>    directive is not followed by an object at the same or a nested level
>>    (sibling or child of current object).

>>    This would also mean, that class and name arguments can not be set for
>>    individual list items (as an inherent limitation of rST's simple
>>    markup syntax).

> No, absolutely not. The current behavior is as intended.

>> c) leave it as an undocumented feature.

> It's not "undocumented", it's under-documented. See (a).

>> The HTML writer currently ignores the class values of definition list items,
>> as there is no matching HTML element but only <dt> and <dd>.

> So let's add a further option:

> d) Modify the HTML writer to transfer the classes attribute from
> definition_list_item elements to the contained term element, and then
> to the HTML <dt> tag.

>> In case a) and c), I suggest a <div> element for definition list items that
>> have class or id/name set.

> -1. An HTML definition list consists of pairs of <dt> & <dd> inside of
><dl></dl>. Inserting <div> tags around a <dt>/<dd> pair would
> invalidate the resulting HTML.

OK. While it works in firefox to style a list item, it fails validation and
is hence not an option.

> I propose doing both (a) & (d). Opinions?

I will work on both. For d), the simpler approach might be to let
visit_term() have a look for possible class values of the parent
definition-list-item node and add them to the <dt> tag.

> In addition, long ago I had an idea to modify the "class" directive
> with a :parent: or :container: option, to assign the class to the
> element containing the directive (the parent element). This option
> could also take an argument, the element type for assignment, so a
> class could be assigned to an arbitrary ancestor of the directive. For
> example:

>     * first list item

>       This class is assigned to this list_item (the immediate parent
> of the directive):

>       .. class:: first
>          :parent:

>       This class is assigned to the bullet_list containing this list_item:

>       .. class:: list
>          :parent: bullet_list

> This could also be used in tables (":parent: entry" puts a class on a
> cell; ":parent: row"; even ":parent: col" could be done, with a bit of
> work).

> See http://docutils.sourceforge.net/docs/dev/todo.html#misc-class &
> http://article.gmane.org/gmane.text.docutils.devel/3165

> I never finished implementing this. Any takers?

Not me. (I agree with the concept but don't feel the urge to put my work for
Docutils in this specific problem).

Thanks,

Günter

Re: [Docutils-develop] [docutils:feature-requests] #43 Make setup.py build wheels.

[Guenter Milde <milde@us...>]

On 2015-02-25, Ben Finney wrote:
> "Günter Milde"  <milde@...> writes:

>> Just add this to setup.cfg:

>> [bdist_wheel]
>> universal = 1

>> See https://packaging.python.org/en/latest/distributing.html#universal-wheels

> According to that document, a “universal wheel” is only appropriate for:

>     [code that is] pure python (i.e. contains no compiled extensions)
>     and support Python 2 and 3.

> By my reading, this means the code base must support Python 2 and Python
> 3 without modification. Docutils does not, and thereby excludes itself
> from being appropriate for such “universal wheel”.

> Have I misunderstood?

No, you just did not read my earlier reply which exatly said this
(unfortunatley not quoted in the "move" report).

But exactly because of our use of 2to3, building "wheels" for Python 2
and 3 respectively would be a time-saver for users downloading the py3k
version. (And take a bit of the urgency out of the "one source for 2 and
3 discussion)

However, whether we are going to do this or label this as wontfix or later,
is up to our "release technician".

Günter

Re: [Docutils-develop] Docutils-develop Digest, Vol 92, Issue 8

[Jeffrey C. Jacobs <darklord@ti...>]

> Message: 13
> Date: Mon, 23 Feb 2015 20:16:18 +0000 (UTC)
> From: Guenter Milde <milde@...>
> Subject: Re: [Docutils-develop] Docutils-develop Digest, Vol 92, Issue
>         6
> To: docutils-develop@...
> Message-ID: <mcg1qi$1t9$1@...>
> Content-Type: text/plain; charset=UTF-8
>
> Dear Jeffrfey,
>
> On 2015-02-19, Jeffrey C. Jacobs wrote:
>
> Nested inline makup is indeed a long standing issue. We have an old set of
> patches as well as a repository branch for it, but development on it stalled.

Yes, I was looking at that, I may attempt to merge in the latest trunk
and then if that fails, create a new branch.

> OTOH, I know that working with branches can be a pain under SVN. If this is
> the barrier hinddring you to start working on this project, I would see this
> as a weighty argument in favour of a VCS-switch.

Not that big a deal; that's what svn switch is for; IMHO the branch
equivalent from git in svn is "svn cp ^/trunk ^/branches/mybranch ;
svn switch ^/branches/mybranch" so really one can be almost git-like
apart from the off-line aspect.  Like I said, I can live with option
a) and thanks for giving me rw access I'm just gonna operate this way
until I hear the next git rumblings.  :)

> In case of a move to a DVCS, Git would be my favourite, I use it at home as
> well as for other projects.

I am too; I find googling is the perfect documentation for git and I
never have much problem with that.  :)

> Thanks for your detailed contribution to the discussion. I hope we will
> find a solution that encourages you to tackle the nested inline markup
> problem.

Thanks.  No rush, but it remains a goal of mine, then maybe back to
making a better screenplay writer.

Jeffrey.

Re: [Docutils-develop] indented class directives

[David Goodger <goodger@py...>]

On Wed, Feb 25, 2015 at 11:53 AM, Guenter Milde <milde@...> wrote:
> Dear David, dear Docutils developers,
>
> trying to tackle bug 266 http://sourceforge.net/p/docutils/bugs/266/
> I came across an interesting feature of the class directive:
>
> The rST specs say:
>
>   The "class" directive sets the "classes" attribute value on its content
>   or on the first immediately following non-comment element.
>
>   -- http://docutils.sourceforge.net/docs/ref/rst/directives.html#id14
>
> This is also true, if the class directive is "nested" at the end of an
> indented text block.
>
> ------------------------------------------------------------------------
>
> Example:
>
>   a block quote
>
>   .. class:: indented
>
> Section with class argument
> ===========================
>
>   .. class:: second indented
>
> paragraph with second class argument, following an empty block-quote
>
>
> This implementation detail allows the "classification" of individual list
> items -- except the first:
>
> * unordered list
>
>   .. class:: classy item
>
> * second item, with class argument

"Except the first": correct, because it's not possible to
differentiate between the overall list and the first list item:

    .. class:: classy list

    * the list itself gets the "classy" class, not this item.

Although:

    * .. class:: classy paragraph

      it is possible to assign a class to the first paragraph in a
list item, which is often good enough.

> definition list:
>
> first term:
>   fist def
>
>   .. class:: for the second dl item
>
> second term:
>   second def
>
> See the XML or pseudoXML output to find the "classified" second item.
>
> .. note::
>    :class: directive example
>
>    even classes set in a directive-block apply not to the containing object
>    (here a note) but the next one, transgressing the "container limit".

This is absolutely intentional.

>    .. class:: html writer problem
>
> The HTML writer currently ignores the class values of definition list items,
> as there is no matching HTML element but only <dt> and <dd>.

I'd consider that a bug of the HTML writer.

> ------------------------------------------------------------------------
>
> The current behaviour is in accordance to the specification, there is no
> discussion of nesting level or indentation so "the first immediately
> following non-comment element" may also be outside the scope of object
> containing the "class" directive.
>
> However, it is non-intuitive, as "normally", indented blocks signify content
> that belongs together.

Non-intuitive if you think it through too logically/hierarchically.
Let your mind go free, flatten your notion of a document, and it makes
perfect sense.

Also, it's damn useful.

> The question now is:
>
> How to proceed from the current situation:
>
> a) document the current behaviour with an example in directives.txt?

Yes. Improved documentation is always good.

> b) change the behaviour: ignore and warn or throw an error, if a "class"
>    directive is not followed by an object at the same or a nested level
>    (sibling or child of current object).
>
>    This would also mean, that class and name arguments can not be set for
>    individual list items (as an inherent limitation of rST's simple
>    markup syntax).

No, absolutely not. The current behavior is as intended.

> c) leave it as an undocumented feature.

It's not "undocumented", it's under-documented. See (a).

> The HTML writer currently ignores the class values of definition list items,
> as there is no matching HTML element but only <dt> and <dd>.

So let's add a further option:

d) Modify the HTML writer to transfer the classes attribute from
definition_list_item elements to the contained term element, and then
to the HTML <dt> tag.

> In case a) and c), I suggest a <div> element for definition list items that
> have class or id/name set.

-1. An HTML definition list consists of pairs of <dt> & <dd> inside of
<dl></dl>. Inserting <div> tags around a <dt>/<dd> pair would
invalidate the resulting HTML.

I propose doing both (a) & (d). Opinions?

In addition, long ago I had an idea to modify the "class" directive
with a :parent: or :container: option, to assign the class to the
element containing the directive (the parent element). This option
could also take an argument, the element type for assignment, so a
class could be assigned to an arbitrary ancestor of the directive. For
example:

    * first list item

      This class is assigned to this list_item (the immediate parent
of the directive):

      .. class:: first
         :parent:

      This class is assigned to the bullet_list containing this list_item:

      .. class:: list
         :parent: bullet_list

This could also be used in tables (":parent: entry" puts a class on a
cell; ":parent: row"; even ":parent: col" could be done, with a bit of
work).

See http://docutils.sourceforge.net/docs/dev/todo.html#misc-class &
http://article.gmane.org/gmane.text.docutils.devel/3165

I never finished implementing this. Any takers?

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

Re: [Docutils-develop] [docutils:feature-requests] #43 Make setup.py build wheels.

[Ben Finney <ben+<python@be...>]

"Günter Milde"  <milde@...> writes:

> Just add this to setup.cfg:
>
> [bdist_wheel]
> universal = 1
>
> See https://packaging.python.org/en/latest/distributing.html#universal-wheels

According to that document, a “universal wheel” is only appropriate for:

    [code that is] pure python (i.e. contains no compiled extensions)
    and support Python 2 and 3.

By my reading, this means the code base must support Python 2 and Python
3 without modification. Docutils does not, and thereby excludes itself
from being appropriate for such “universal wheel”.

Have I misunderstood?

-- 
 \          “When we talk to God, we're praying. When God talks to us, |
  `\         we're schizophrenic.” —Jane Wagner, via Lily Tomlin, 1985 |
_o__)                                                                  |
Ben Finney

[Docutils-develop] indented class directives

[Guenter Milde <milde@us...>]

Dear David, dear Docutils developers,

trying to tackle bug 266 http://sourceforge.net/p/docutils/bugs/266/
I came across an interesting feature of the class directive:

The rST specs say:

  The "class" directive sets the "classes" attribute value on its content
  or on the first immediately following non-comment element.
  
  -- http://docutils.sourceforge.net/docs/ref/rst/directives.html#id14

This is also true, if the class directive is "nested" at the end of an
indented text block.

------------------------------------------------------------------------

Example:

  a block quote
  
  .. class:: indented
  
Section with class argument
===========================

  .. class:: second indented
  
paragraph with second class argument, following an empty block-quote


This implementation detail allows the "classification" of individual list
items -- except the first:

* unordered list

  .. class:: classy item
  
* second item, with class argument

definition list:

first term:
  fist def
  
  .. class:: for the second dl item
  
second term:
  second def
    
See the XML or pseudoXML output to find the "classified" second item.

.. note::
   :class: directive example

   even classes set in a directive-block apply not to the containing object
   (here a note) but the next one, transgressing the "container limit".
   
   .. class:: html writer problem
    
The HTML writer currently ignores the class values of definition list items,
as there is no matching HTML element but only <dt> and <dd>.

------------------------------------------------------------------------

The current behaviour is in accordance to the specification, there is no
discussion of nesting level or indentation so "the first immediately
following non-comment element" may also be outside the scope of object
containing the "class" directive.

However, it is non-intuitive, as "normally", indented blocks signify content
that belongs together.

The question now is:

How to proceed from the current situation:

a) document the current behaviour with an example in directives.txt?

b) change the behaviour: ignore and warn or throw an error, if a "class"
   directive is not followed by an object at the same or a nested level
   (sibling or child of current object).
    
   This would also mean, that class and name arguments can not be set for
   individual list items (as an inherent limitation of rST's simple
   markup syntax).
    
c) leave it as an undocumented feature.
   
The HTML writer currently ignores the class values of definition list items,
as there is no matching HTML element but only <dt> and <dd>.

In case a) and c), I suggest a <div> element for definition list items that
have class or id/name set.

Günter

[Docutils-develop] [docutils:feature-requests] #39 rst2html: do not generate colgroup tags for tables

[Brecht Machiels <darklite09@us...>]

[Docutils-develop] [docutils:feature-requests] #43 Make setup.py build wheels.

[Günter Milde <milde@us...>]

[Docutils-develop] [docutils:bugs] #271 Make setup.py build wheels.

[Günter Milde <milde@us...>]

[Docutils-develop] [docutils:bugs] #247 [rst_html4css1] SVGs should be wrapped in <IMG> tag, not <OBJECT>

[Günter Milde <milde@us...>]

Re: [Docutils-develop] Git/GitHub conclusion?

[engelbert gruber <engelbert.gruber@gm...>]

The way i learned to program is to stay away from the Computer.
Draft the solution first on paper.
The problems i See the most are due to not listening RTFM etc.

Coding and code administration never was not any minor issue , never near
mediocre.

Re: [Docutils-develop] Docutils-develop Digest, Vol 92, Issue 6

[Guenter Milde <milde@us...>]

Dear Jeffrfey,

On 2015-02-19, Jeffrey C. Jacobs wrote:


> What I'm more bully about is my +3 on being able to contribute
> change-sets, not just diffs.  As a developer, I feel my work is
> trivialized if my contribution, that I may have worked on for a month,
> is trivialized to just one, single, monolithic diff.  I much prefer
> the work model as a branch, that makes changes over time, and then
> when I'm ready for code review I can provide the diff but my
> change-set would be public and thus the process at *how* I created the
> patch is also exposed.  This, IMHO, is what should become part of
> trunk, not just the one-time, one-page patch.

I understand. 

> Put another way, I've mentioned before I'd like, someday, to take on
> the massive change to states.py to make it support nested markup,
> which has been on the nice-to-have list of RST for a long, long time.
> I think it can be done, it's just a matter of sitting down, changing
> the way the state is handled and making it happen.  But it's a big
> process and the interim steps in the test-driven development will be
> significant in understanding the nature of the final "patch"
> contributed.  It's not like this would be a trivial diff.  And that
> belies the depth of contribution because if I just contribute that one
> patch, hasn't my effort been commensurate to more than one diff
> applied?  The change-set would prove that this isn't just a trivial
> patch but rather a massive change whose steps and history should be
> reflected in the lifespan of the trunk.

Nested inline makup is indeed a long standing issue. We have an old set of
patches as well as a repository branch for it, but development on it stalled.
If you plan to work on it and given your intention to let this be a well
documented and test driven development, I don't see a reason preventing you
to commit your changes directly to the existing (or an alterntive) "nested"
branch of the core repository.

OTOH, I know that working with branches can be a pain under SVN. If this is
the barrier hinddring you to start working on this project, I would see this
as a weighty argument in favour of a VCS-switch. 

...

> Consider though the DVCS use-case:

> c) User pulls the latest docutils, branches, does multiple checkins,
> test-driven development, occasional fetch-rebase operations to bring
> in the latest master, and then posts the branch to the ticket as ready
> for merging back to master.  No concerns about reintegration, or
> potential .mergeinfo corruption.  Simple, succinct, and preserving
> change-sets.

> Case c) is true for all DVCS.  I've used Bazaar and Git, must say
> forget about Bazaar but have absolutely no issue with Mercurial if
> removing Git from discussion will mollify some of the argument.  I'm
> no git expert but usually find what I need to know in seconds thanks
> to google.  So there are some fundamental concerns about the viability
> of DVCS in general so have my arguments at least help dispel those
> concerns of the potential ephemeral nature of DVCS and show how it can
> be a better development model.

In case of a move to a DVCS, Git would be my favourite, I use it at home as
well as for other projects.

> I guess I'm just pro change-set development and against diff-patch
> development just not convinced git or github is the best solution.

Thanks for your detailed contribution to the discussion. I hope we will
find a solution that encourages you to tackle the nested inline markup
problem.

Günter 

[Docutils-develop] [docutils:feature-requests] #39 rst2html: do not generate colgroup tags for tables

[Christian Weiske <cweiske@us...>]