structuredtext-checkins Mailing List for reStructuredText

Status: Pre-Alpha

Brought to you by: goodger

structuredtext-checkins — CVS checkin messages

You can subscribe to this list here.

2001	_Jan	_Feb	_Mar	_Apr	_May	_Jun	_Jul	_Aug (83)	_Sep (171)	_Oct (49)	_Nov (58)	_Dec
2002	_Jan (34)	_Feb (76)	_Mar (111)	_Apr (47)	_May	_Jun	_Jul	_Aug	_Sep	_Oct	_Nov	_Dec

Flat | Threaded

1 2 3 .. 26 > >> (Page 1 of 26)

[Structuredtext-checkins] CVS: web index.txt,NONE,1.1

From: David G. <go...@us...> - 2002-04-21 15:43:35

Update of /cvsroot/structuredtext/web
In directory usw-pr-cvs1:/tmp/cvs-serv408/web

Added Files:
	index.txt 
Log Message:
project retirement

--- NEW FILE: index.txt ---
====================
 |reStructuredText|
====================

.. meta::
   :http-equiv=Refresh: 15;URL=http://docutils.sourceforge.net/

:Date: $Date: 2002/04/21 15:43:32 $

The reStructuredText_ project has moved!  It is now part of the
Docutils_ project; you should be redirected to the new location
momentarily.  `Click here to go to the Docutils project home page
immediately.`__

You may also `visit the inactive reStructuredText home page`__.

__ Docutils_
__ index-old.html
.. _reStructuredText: http://docutils.sourceforge.net/rst.html
.. _Docutils: http://docutils.sourceforge.net/
.. |reStructuredText| image:: title.png

[Structuredtext-checkins] CVS: web index.html.template,1.5,NONE

From: David G. <go...@us...> - 2002-04-21 15:43:16

Update of /cvsroot/structuredtext/web
In directory usw-pr-cvs1:/tmp/cvs-serv361a/web

Removed Files:
	index.html.template 
Log Message:
project retirement

--- index.html.template DELETED ---

[Structuredtext-checkins] CVS: web index.html,1.5,NONE

From: David G. <go...@us...> - 2002-04-21 15:42:51

Update of /cvsroot/structuredtext/web
In directory usw-pr-cvs1:/tmp/cvs-serv32682a/web

Removed Files:
	index.html 
Log Message:
project retirement

--- index.html DELETED ---

[Structuredtext-checkins] CVS: web index-old.html.template,NONE,1.1

From: David G. <go...@us...> - 2002-04-21 15:42:44

Update of /cvsroot/structuredtext/web
In directory usw-pr-cvs1:/tmp/cvs-serv32643/web

Added Files:
	index-old.html.template 
Log Message:
project retirement

--- NEW FILE: index-old.html.template ---
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- $Id: index-old.html.template,v 1.1 2002/04/21 15:42:41 goodger Exp $ -->
#  latest_rst_release = 'restructuredtext-0.4.tar.gz'
#  latest_dps_release = 'dps-0.4.tar.gz'
<HTML>
<HEAD>
   <TITLE>reStructuredText</TITLE>
</HEAD>
<BODY bgcolor="#F0FFF0">

<P><A HREF="http://sourceforge.net/projects/structuredtext/" 
><IMG SRC="title.png" ALT="reStructuredText" BORDER=0 ALIGN=bottom></A></P>

<P><FONT color="red">This project is now <B>inactive</B>.  All
development has been taken over by the <A
HREF="http://docutils.sourceforge.het/">Docutils</A>
project.</FONT></P>

<P><I>last updated: `date`</I></P>

<P>reStructuredText is an easy-to-read, what-you-see-is-what-you-get plaintext
markup syntax and parser system. It is useful for in-line program
documentation (such as Python docstrings), for quickly creating simple web
pages, and for standalone documents. reStructuredText is designed for
extensibility for specific application domains. It is a candidate markup
syntax for the <A HREF="http://docstring.sourceforge.net/">Python Docstring
Processing System</A>. reStructuredText is a revision and reinterpretation of
the <A HREF="http://dev.zope.org/Members/jim/StructuredTextWiki/FrontPage/"
>StructuredText</A> and <A HREF="http://docutils.sourceforge.net/mirror/setext.html"
>Setext</A> lightweight markup systems.</P>

<P>The primary goal of the reStructuredText project is to define and implement
a markup syntax for use in Python docstrings and other documentation domains,
that is readable and simple, yet powerful enough for non-trivial use. The
intended purpose of the markup is the conversion of reStructuredText documents
into useful structured data formats.</P>

<P>See <A HREF="http://docstring.sourceforge.net/dps/statemachine.py"
><TT>statemachine.py</TT></A> for an example of a Python module fully
documented using reStructuredText.</P>

<H2>Project Status</H2>

<P>This project is now <B>inactive</B>.  All development has been
taken over by the <A
HREF="http://docutils.sourceforge.het/">Docutils</A> project.</P>

<P>This project consists of a Python package,
&ldquo;<TT>dps.parsers.restructuredtext</TT>&rdquo;, a component of the <A
HREF="http://docstring.sourceforge.net/">Python Docstring Processing System
(DPS)</A>. The reStructuredText parser is functionally complete.</P>

<H3><A NAME="snapshots">CVS Snapshots</A></H3>

<P>The final CVS snapshots are available below:</P>

<UL>

 <LI><P><A
     HREF="http://structuredtext.sourceforge.net/rst-snapshot.tgz"
     >reStructuredText code, tests, documentation, and specifications</A>.
     Except for a few typos, this is equivalent to the final release
     package.</P></LI>

 <LI><P><A
     HREF="http://docstring.sourceforge.net/dps-snapshot.tgz"
     >DPS code, tests, and specifications (no user docs yet)</A>
     Except for a few typos, this is equivalent to the final release
     package.</P></LI>

 <LI><P><A
     HREF="http://structuredtext.sourceforge.net/rst-web-snapshot.tgz"
     >reStructuredText homepage files</A>
     </P></LI>

 <LI><P><A
     HREF="http://structuredtext.sourceforge.net/rst-sandbox-snapshot.tgz"
     >reStructuredText Sandbox files</A>
     </P></LI>

</UL>

<H3><A NAME="releases">Project Releases</A></H3>

<P>Development has been suspended at this site.  All new development is
taking place at the <A HREF="http://docutils.sourceforge.net">Docutils</A>
project.</P>

<P>The <A
HREF="http://prdownloads.sourceforge.net/structuredtext/`latest_rst_release`"
>final project release package (`latest_rst_release`)</A> and past project
releases can be downloaded from the <A
HREF="http://sourceforge.net/project/showfiles.php?group_id=7050">project
files page</A>. The <A
HREF="http://prdownloads.sourceforge.net/docstring/`latest_dps_release`"
>final DPS package (`latest_dps_release`)</A> is also required. <A
HREF="http://sourceforge.net/cvs/?group_id=7050">Anonymous CVS access is
available.</A> You can also <A
HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/structuredtext/restructuredtext/"
>browse the latest reStructuredText source files (CVS) individually</A>, and
read the final <A HREF="README.html">README</A> and <A
HREF="HISTORY.html">HISTORY</A> files.</P>

<H2>User Documentation</H2>

<P>The user documentation files are located in the <TT>docs</TT> directory of the <A
HREF="http://prdownloads.sourceforge.net/structuredtext/`latest_rst_release`"
>latest project release package</A> (which may not be up to date). The
up-to-date working documents (from CVS) may be accessed individually below,
or from the <A HREF="#snapshots">snapshots</A> above. You can also <A
HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/structuredtext/restructuredtext/docs/"
>browse the CVS repository</A> directly.</P>

<UL>

 <LI><P><A HREF="docs/quickstart.html">A ReStructuredText Primer</A> (HTML file),
        and <A HREF="docs/quickstart.txt">A ReStructuredText Primer</A> (text source).
     </P></LI>

 <LI><P><A
     HREF="docs/quickref.html"
     >Quick reStructuredText</A> (user reference)
     </P></LI>
</UL>

<H2>Specification</H2>

<P>All of the specification files are located in the <TT>spec</TT> directory of the <A
HREF="http://prdownloads.sourceforge.net/structuredtext/`latest_rst_release`"
>latest project release package</A> (which may not be up to date). The
up-to-date working documents (from CVS) may be accessed individually below,
or from the <A HREF="#snapshots">snapshots</A> above. You can also <A
HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/structuredtext/restructuredtext/spec/"
>browse the CVS repository</A> directly.</P>

<UL>
 <LI><P><A
     HREF="spec/introduction.txt"
     >An Introduction to reStructuredText</A>
     </P></LI>

 <LI><P><A
     HREF="spec/reStructuredText.txt"
     >reStructuredText Markup Specification</A>
     </P></LI>

 <LI><P><A
     HREF="spec/alternatives.txt"
     >A Record of reStructuredText Syntax Alternatives</A>
     </P></LI>

 <LI><P><A
     HREF="spec/problems.txt"
     >Problems With StructuredText</A>
     </P></LI>

 <LI><P><A
     HREF="spec/rst-notes.txt"
     >Notes</A>
     </P></LI>
</UL>

<H2>You Can Help!</H2>

<P>If you can test, administrate, or contribute code, ideas, bug
reports, yummy treats, computer equipment, and/or large sums of money,
please <A HREF="mailto:go...@us...">contact the
project administrator</A>.</P>

<H2>Project Info</H2>

<UL>

 <LI><P><A
     HREF="http://sourceforge.net/projects/structuredtext/"
     >Project Summary page</A>: <A
     HREF="http://sourceforge.net/tracker/?atid=107050&group_id=7050" 
     >Bug reports</A>, <A
     HREF="http://sourceforge.net/tracker/?atid=307050&group_id=7050"
     >patches</A>, <A
     HREF="http://sourceforge.net/tracker/?atid=357050&group_id=7050"
     >feature requests</A>, <A
     HREF="http://sourceforge.net/mail/?group_id=7050"
     >mailing lists</A>, <A
     HREF="http://sourceforge.net/news/?group_id=7050"
     >news</A></P></LI>

 <LI><P><A
     HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/structuredtext/restructuredtext/"
     >reStructuredText CVS repository</A></P></LI>

 <LI><P>Project administrator:
     <A HREF="mailto:go...@us...">David Goodger</A></P></LI>

 <LI><P>Please direct discussions to the
     <A HREF="http://www.python.org/sigs/doc-sig/">Python Documentation
     Special Interest Group (Doc-SIG)</A>:
     <A HREF="mailto:do...@py...">do...@py...</A></P></LI>

 <LI><P>Page generated using Alex Martelli's
     <A HREF="http://aspn.activestate.com/ASPN/Python/Cookbook/Recipe/52305">
     YAPTU</A> (Yet Another Python Templating Utility)</P></LI>

 <LI><P>Powered by <A href="http://www.python.org/">
     <IMG src="PyBanner016.png" ALIGN="top" ALT="Python" BORDER="0"></A>
     </P></LI>

 <LI><P>Hosted by <A href="http://sourceforge.net">
     <IMG src="http://sourceforge.net/sflogo.php?group_id=7050" width="88"
          height="31" border="0" alt="SourceForge Logo" ALIGN="top"></A>
     </P></LI>

</UL>

</BODY>
</HTML>

[Structuredtext-checkins] CVS: restructuredtext HISTORY.txt,1.50,1.51

From: David G. <go...@us...> - 2002-04-20 16:23:44

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv10073/restructuredtext

Modified Files:
	HISTORY.txt 
Log Message:
*** empty log message ***

Index: HISTORY.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/HISTORY.txt,v
retrieving revision 1.50
retrieving revision 1.51
diff -C2 -d -r1.50 -r1.51
*** HISTORY.txt	19 Apr 2002 01:49:04 -0000	1.50
--- HISTORY.txt	20 Apr 2002 16:23:41 -0000	1.51
***************
*** 6,10 ****
  :Contact: go...@us...
  :Date: $Date$
! :Website: http://structuredtext.sourceforge.net/
  
  
--- 6,10 ----
  :Contact: go...@us...
  :Date: $Date$
! :Web-site: http://structuredtext.sourceforge.net/

[Structuredtext-checkins] CVS: restructuredtext MANIFEST.in,NONE,1.1

From: David G. <go...@us...> - 2002-04-19 02:58:46

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv6617/restructuredtext

Added Files:
	MANIFEST.in 
Log Message:
for distutils

--- NEW FILE: MANIFEST.in ---
include *.txt
include *.py
recursive-include docs *
recursive-include spec *
recursive-include test *
recursive-include tools *

[Structuredtext-checkins] CVS: restructuredtext/test RSTTestSupport.py,1.12,1.13

From: David G. <go...@us...> - 2002-04-19 02:37:38

Update of /cvsroot/structuredtext/restructuredtext/test
In directory usw-pr-cvs1:/tmp/cvs-serv1420/restructuredtext/test

Modified Files:
	RSTTestSupport.py 
Log Message:
fixed imports

Index: RSTTestSupport.py
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/test/RSTTestSupport.py,v
retrieving revision 1.12
retrieving revision 1.13
diff -C2 -d -r1.12 -r1.13
*** RSTTestSupport.py	6 Feb 2002 02:19:04 -0000	1.12
--- RSTTestSupport.py	19 Apr 2002 02:37:35 -0000	1.13
***************
*** 31,46 ****
  import sys, os, unittest, re, difflib, types, inspect
  from pprint import pformat
! 
! # try to import the current working version if possible
! try:
!     sys.path.insert(0, os.pardir)       # running in test framework dir?
!     import restructuredtext             # or restructuredtext on path?
! except ImportError:                     # try to run installed code
!     from dps.parsers import restructuredtext
! 
! from restructuredtext import states
! from restructuredtext import tableparser
! from restructuredtext import directives
! from restructuredtext import languages
  from dps.statemachine import string2lines
  import dps.utils
--- 31,37 ----
  import sys, os, unittest, re, difflib, types, inspect
  from pprint import pformat
! from dps.parsers import restructuredtext
! from dps.parsers.restructuredtext import states, tableparser, directives, \
!       languages
  from dps.statemachine import string2lines
  import dps.utils

[Structuredtext-checkins] CVS: restructuredtext/restructuredtext/directives misc.py,1.2,1.3

From: David G. <go...@us...> - 2002-04-19 02:37:25

Update of /cvsroot/structuredtext/restructuredtext/restructuredtext/directives
In directory usw-pr-cvs1:/tmp/cvs-serv1361/restructuredtext/restructuredtext/directives

Modified Files:
	misc.py 
Log Message:
fixed imports

Index: misc.py
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/restructuredtext/directives/misc.py,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** misc.py	11 Mar 2002 03:21:44 -0000	1.2
--- misc.py	19 Apr 2002 02:37:21 -0000	1.3
***************
*** 16,20 ****
  
  
- from restructuredtext import states
  from dps import nodes
  
--- 16,19 ----

[Structuredtext-checkins] CVS: restructuredtext/spec introduction.txt,1.11,1.12

From: David G. <go...@us...> - 2002-04-19 01:49:40

Update of /cvsroot/structuredtext/restructuredtext/spec
In directory usw-pr-cvs1:/tmp/cvs-serv24777/restructuredtext/spec

Modified Files:
	introduction.txt 
Log Message:
updated

Index: introduction.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/spec/introduction.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** introduction.txt	18 Apr 2002 03:11:14 -0000	1.11
--- introduction.txt	19 Apr 2002 01:49:37 -0000	1.12
***************
*** 252,256 ****
  
  Version 0.4 of the reStructuredText_ and `Docstring Processing
! System`_ projects were released on 2002-04-??.  The two projects were
  immediately merged, renamed to "Docutils_", and a 0.1 release soon
  followed.
--- 252,256 ----
  
  Version 0.4 of the reStructuredText_ and `Docstring Processing
! System`_ projects were released in April 2002.  The two projects were
  immediately merged, renamed to "Docutils_", and a 0.1 release soon
  followed.

[Structuredtext-checkins] CVS: restructuredtext setup.py,1.7,1.8

From: David G. <go...@us...> - 2002-04-19 01:49:28

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv24736/restructuredtext

Modified Files:
	setup.py 
Log Message:
updated

Index: setup.py
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/setup.py,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** setup.py	18 Apr 2002 02:43:20 -0000	1.7
--- setup.py	19 Apr 2002 01:49:25 -0000	1.8
***************
*** 13,17 ****
            author = 'David Goodger',
            author_email = 'go...@us...',
!           license = 'public domain',
            packages = ['dps.parsers.restructuredtext',
                        'dps.parsers.restructuredtext.directives',
--- 13,17 ----
            author = 'David Goodger',
            author_email = 'go...@us...',
!           license = 'public domain, Python (see COPYING.txt)',
            packages = ['dps.parsers.restructuredtext',
                        'dps.parsers.restructuredtext.directives',

[Structuredtext-checkins] CVS: restructuredtext README.txt,1.6,1.7

From: David G. <go...@us...> - 2002-04-19 01:49:19

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv24699/restructuredtext

Modified Files:
	README.txt 
Log Message:
updated

Index: README.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/README.txt,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** README.txt	18 Apr 2002 02:49:03 -0000	1.6
--- README.txt	19 Apr 2002 01:49:16 -0000	1.7
***************
*** 8,15 ****
  :Web-site: http://structuredtext.sourceforge.net/
  
! Thank you for downloading the reStructuredText project archive.  As
! this is a work in progress, please check the project web site for
! updated working files.  The latest release archive is available at
! http://sourceforge.net/project/showfiles.php?group_id=7050.
  
  reStructuredText is an input parser component of the `Python Docstring
--- 8,15 ----
  :Web-site: http://structuredtext.sourceforge.net/
  
! Thank you for downloading the reStructuredText project archive.
! Development has been transferred to the Docutils_ project.  As this is
! a work in progress, please check the project web site for updated
! working files.
  
  reStructuredText is an input parser component of the `Python Docstring
***************
*** 21,24 ****
--- 21,25 ----
  latest DPS package, available from http://docstring.sourceforge.net/.
  
+ .. _Docutils: http://docutils.sourceforge.net/
  .. _Python Docstring Processing System:
     http://docstring.sourceforge.net/

[Structuredtext-checkins] CVS: restructuredtext HISTORY.txt,1.49,1.50

From: David G. <go...@us...> - 2002-04-19 01:49:07

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv24642/restructuredtext

Modified Files:
	HISTORY.txt 
Log Message:
updated

Index: HISTORY.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/HISTORY.txt,v
retrieving revision 1.49
retrieving revision 1.50
diff -C2 -d -r1.49 -r1.50
*** HISTORY.txt	18 Apr 2002 02:48:48 -0000	1.49
--- HISTORY.txt	19 Apr 2002 01:49:04 -0000	1.50
***************
*** 32,38 ****
  
  
! Release 0.4 (2002-04-??)
  ========================
  
  General: updated docstrings for new field list syntax (bibliographic
  info); changed contact email addresses.
--- 32,44 ----
  
  
! Release 0.4 (2002-04-18)
  ========================
  
+ This is the final release of reStructuredText as an independent
+ package.  Development is being transferred to the Docutils_ project
+ immediately.
+ 
+ .. _Docutils: http://docutils.sourceforge.net/
+ 
  General: updated docstrings for new field list syntax (bibliographic
  info); changed contact email addresses.
***************
*** 44,47 ****
--- 50,55 ----
    - Modified for import by install.py.
    - Added 'restructuredtext.languages' subpackage.
+ 
+ * COPYING.txt: Added to project.
  
  * docs: Subdirectory added. Contains quickref.html by Tony Ibbs and

[Structuredtext-checkins] CVS: restructuredtext COPYING.txt,NONE,1.1

From: David G. <go...@us...> - 2002-04-19 01:48:36

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv24548/restructuredtext

Added Files:
	COPYING.txt 
Log Message:
copyright details

--- NEW FILE: COPYING.txt ---
==========================
 Copying reStructuredText
==========================

:Author: David Goodger
:Contact: go...@us...
:Date: $Date: 2002/04/19 01:48:33 $
:Web-site: http://structuredtext.sourceforge.net/

Most of the files included in this project are in the public domain,
and therefore have no license requirement and no restrictions on
copying or usage.  The only exception is:

- test/difflib.py, copyright by the Python Software Foundation,
  licensed under the `Python 2.2 license`_.  This file is included for
  compatibility with Python versions less than 2.2; if you have Python
  2.2 or higher, difflib.py is not needed and may be removed.  (It's
  only used to report test failures anyhow; it isn't installed
  anywhere.  The included file is a pre-generator version of the
  difflib.py module included in Python 2.2.)

(Disclaimer: I am not a lawyer.)  The Python license is OSI-approved_
and GPL-compatible_.  Although complicated by multiple owners and lots
of legalese, it basically lets you copy, use, modify, and redistribute
files as long as you keep the copyright attribution intact, note any
changes you make, and don't use the owner's name in vain.

.. _Python 2.2 license: http://www.python.org/2.2/license.html
.. _OSI-approved: http://opensource.org/licenses/
.. _GPL-compatible: http://www.gnu.org/philosophy/license-list.html

[Structuredtext-checkins] CVS: restructuredtext/spec introduction.txt,1.10,1.11

From: David G. <go...@us...> - 2002-04-18 03:11:16

Update of /cvsroot/structuredtext/restructuredtext/spec
In directory usw-pr-cvs1:/tmp/cvs-serv19595/restructuredtext/spec

Modified Files:
	introduction.txt 
Log Message:
Added targets.

Index: introduction.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/spec/introduction.txt,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** introduction.txt	18 Apr 2002 02:42:48 -0000	1.10
--- introduction.txt	18 Apr 2002 03:11:14 -0000	1.11
***************
*** 290,293 ****
--- 290,295 ----
      http://structuredtext.sourceforge.net/HISTORY.txt
  .. _PEP 287: http://docutils.sourceforge.net/spec/pep-0287.txt
+ .. _comp.lang.python: news:comp.lang.python
+ .. _Python-dev: http://mail.python.org/pipermail/python-dev/
  .. _Docutils: http://docutils.sourceforge.net/
  .. _master PEP repository: http://www.python.org/peps/

[Structuredtext-checkins] CVS: restructuredtext README.txt,1.5,1.6

From: David G. <go...@us...> - 2002-04-18 02:49:06

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv14320/restructuredtext

Modified Files:
	README.txt 
Log Message:
fixed whitespace & updated

Index: README.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/README.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -C2 -d -r1.5 -r1.6
*** README.txt	16 Mar 2002 05:42:50 -0000	1.5
--- README.txt	18 Apr 2002 02:49:03 -0000	1.6
***************
*** 8,14 ****
  :Web-site: http://structuredtext.sourceforge.net/
  
! Thank you for downloading the reStructuredText project archive. As
  this is a work in progress, please check the project web site for
! updated working files. The latest release archive is available at
  http://sourceforge.net/project/showfiles.php?group_id=7050.
  
--- 8,14 ----
  :Web-site: http://structuredtext.sourceforge.net/
  
! Thank you for downloading the reStructuredText project archive.  As
  this is a work in progress, please check the project web site for
! updated working files.  The latest release archive is available at
  http://sourceforge.net/project/showfiles.php?group_id=7050.
  
***************
*** 17,22 ****
  "dps.parsers.restructuredtext".
  
! To run the code, Python 2.0 or later must already be installed. You
! can get Python from http://www.python.org/. You will also need the
  latest DPS package, available from http://docstring.sourceforge.net/.
  
--- 17,22 ----
  "dps.parsers.restructuredtext".
  
! To run the code, Python 2.0 or later must already be installed.  You
! can get Python from http://www.python.org/.  You will also need the
  latest DPS package, available from http://docstring.sourceforge.net/.
  
***************
*** 33,37 ****
    releases.
  
! * setup.py: Installation script. See "Installation" below.
  
  * install.py: Quick & dirty installation script.
--- 33,37 ----
    releases.
  
! * setup.py: Installation script.  See "Installation" below.
  
  * install.py: Quick & dirty installation script.
***************
*** 40,46 ****
    package ``dps.parsers.restructuredtext``.
  
! * test: The unit test directory (currently experimental). Not required
!   to use the software, but very useful if you're planning to modify
!   it.
  
  * tools: Directory for standalone scripts that use reStructuredText.
--- 40,46 ----
    package ``dps.parsers.restructuredtext``.
  
! * test: The unit test directory (currently experimental).  Not
!   required to use the software, but very useful if you're planning to
!   modify it.
  
  * tools: Directory for standalone scripts that use reStructuredText.
***************
*** 55,62 ****
      HTML4/CSS1.  Uses the default.css stylesheet.
  
! * spec: The project specification directory. Contains the markup
    syntax spec and implementation notes.
  
! * docs: The project documentation directory.
  
  
--- 55,62 ----
      HTML4/CSS1.  Uses the default.css stylesheet.
  
! * spec: The project specification directory.  Contains the markup
    syntax spec and implementation notes.
  
! * docs: The project user documentation directory.
  
  
***************
*** 64,70 ****
  ============
  
! The first step is to expand the .tar.gz archive. It contains a
! distutils setup file "setup.py". OS-specific installation instructions
! follow.
  
  Linux, Unix, MacOS X
--- 64,70 ----
  ============
  
! The first step is to expand the .tar.gz archive.  It contains a
! distutils setup file "setup.py".  OS-specific installation
! instructions follow.
  
  Linux, Unix, MacOS X
***************
*** 82,89 ****
  
     If the python executable isn't on your path, you'll have to specify
!    the complete path, such as /usr/local/bin/python. You may need root
!    permissions to complete this step.
  
! You can also just run install.py; it does the same thing.
  
  Windows
--- 82,89 ----
  
     If the python executable isn't on your path, you'll have to specify
!    the complete path, such as /usr/local/bin/python.  You may need
!    root permissions to complete this step.
  
!    You can also just run install.py; it does the same thing.
  
  Windows
***************
*** 114,128 ****
     If the file isn't a "Python module", the line endings are probably
     also wrong, and you will need to set up your system to recognize
!    ".py" file extensions as Python files. See
     http://gotools.sourceforge.net/mac/python.html for detailed
!    instructions. Once set up, it's easiest to start over by expanding
     the archive again.
  
! 3. The distutils options window will appear. From the "Command" popup
     list choose "install", click "Add", then click "OK".
  
  If install.py is a "Python module" (see step 2 above if it isn't), you
! can run it instead of the above. The distutils options windown will
! not appear.
  
  
--- 114,138 ----
     If the file isn't a "Python module", the line endings are probably
     also wrong, and you will need to set up your system to recognize
!    ".py" file extensions as Python files.  See
     http://gotools.sourceforge.net/mac/python.html for detailed
!    instructions.  Once set up, it's easiest to start over by expanding
     the archive again.
  
! 3. The distutils options window will appear.  From the "Command" popup
     list choose "install", click "Add", then click "OK".
  
  If install.py is a "Python module" (see step 2 above if it isn't), you
! can run it instead of steps 2 and 3 above.  The distutils options
! windown will not appear.
! 
! 
! Usage
! =====
! 
! After installing both the reStructuredText and DPS packages, start
! with the html.py and publish.py front-ends from the unpacked
! reStructuredText "tools" subdirectory.  Both take up to two arguments,
! the source path and destination path, with STDIN and STDOUT being the
! defaults.
  
  
***************
*** 131,134 ****
--- 141,145 ----
     mode: indented-text
     indent-tabs-mode: nil
+    sentence-end-double-space: t
     fill-column: 70
     End:

[Structuredtext-checkins] CVS: restructuredtext HISTORY.txt,1.48,1.49

From: David G. <go...@us...> - 2002-04-18 02:48:51

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv14252/restructuredtext

Modified Files:
	HISTORY.txt 
Log Message:
fixed whitespace & updated

Index: HISTORY.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/HISTORY.txt,v
retrieving revision 1.48
retrieving revision 1.49
diff -C2 -d -r1.48 -r1.49
*** HISTORY.txt	14 Apr 2002 19:40:19 -0000	1.48
--- HISTORY.txt	18 Apr 2002 02:48:48 -0000	1.49
***************
*** 26,40 ****
      Yee, Moshe Zadka
  
! (I'm still waiting for contributions of yummy treats, computer
! equipment, and cold hard cash. :-) Hopefully I haven't forgotten
! anyone or misspelled any names; apologies (and please let me know!) if
! I have.
  
  
! Release 0.4? (pending)
  ========================
  
! Updated docstrings for new field list syntax (bibliographic info).
! Changed contact email addresses.
  
  * install.py: Added to project.
--- 26,40 ----
      Yee, Moshe Zadka
  
! (I did get some yummy treats, but I'm still waiting for contributions
! of computer equipment and cold hard cash :-).)  Hopefully I haven't
! forgotten anyone or misspelled any names; apologies (and please let me
! know!) if I have.
  
  
! Release 0.4 (2002-04-??)
  ========================
  
! General: updated docstrings for new field list syntax (bibliographic
! info); changed contact email addresses.
  
  * install.py: Added to project.
***************
*** 127,134 ****
    - Added ``Body.parse_extension_attributes()``.
  
! * restructuredtest/tableparser.py: Added to project. Contains the
    TableParser class.
  
! * restructuredtext/test_states.py: Refactored to test directory. This
    file removed.
  
--- 127,134 ----
    - Added ``Body.parse_extension_attributes()``.
  
! * restructuredtest/tableparser.py: Added to project.  Contains the
    TableParser class.
  
! * restructuredtext/test_states.py: Refactored to test directory.  This
    file removed.
  
***************
*** 138,192 ****
    - Added directive module & function import support.
  
! * restructuredtext/directives/misc.py: Implementation of a
!   test directive, 'restructuredtext-test-directive'. Added to project.
  
  * restructuredtext/directives/admonitions.py: Implementation of
!   admonition directives 'note', 'caution', etc. Added to project.
  
  * restructuredtext/directives/components.py: Implementation of
!   document components directives 'contents', 'footnotes', etc. Added
    to project.
  
  * restructuredtext/directives/images.py: Implementation of
!   directives 'image' & 'figure'. Added to project.
  
  * restructuredtext/directives/html.py: Implementation of
!   HTML-specific directives 'meta' & 'imagemap'. Added to project.
  
! * restructuredtext/languages: Subpackage added to project. Contains
    modules for language-dependent language-dependent parser features.
    Includes en.py for English.
  
! * test: Subdirectory added. The top-level consists of a modular test
    framework begun by Garth Kidd.
  
  * test/test_states: Subdirectory added; contains test modules
!   refactored from restructuredtext/test_states.py:
! 
!   - Added unit tests from Garth Kidd.
!   - Changed to match state.RSTStateMachine.run()'s return value.
!   - Added explanatory text to several tests (makes them
!     self-documenting: "what am I testing?").
!   - Added tests for overline-titles, duplicate link targets.
!   - Moved some tests around to where they make more sense.
!   - Added enumerated list tests.
!   - Clarified some edge-case tests.
!   - Added tests for field lists, option lists.
!   - Added tests for tables.
!   - Added tests for table parser.
!   - New tests for literal_block edge cases.
!   - Added tests for empty list items.
!   - New test for comment edge case.
!   - Added 'term : classifier' tests.
!   - Added auto-numbered footnote tests.
!   - Updated 'test directive' tests.
!   - Added 'unknown directive' tests.
!   - Added tests for admonitions and image/figure directives.
  
! * tools: Subdirectory added. Contains quicktest.py by Garth Kidd, a
!   a front-end to the reStructuredText parser; and publish.py, a
!   minimal front-end to the Docutils Publisher.
  
! * sandbox: Subdirectory added; for playing around. It's OK to make
    a mess!
  
--- 138,173 ----
    - Added directive module & function import support.
  
! * restructuredtext/directives/misc.py: Implementation of a test
!   directive, 'restructuredtext-test-directive'.  Added to project.
  
  * restructuredtext/directives/admonitions.py: Implementation of
!   admonition directives 'note', 'caution', etc.  Added to project.
  
  * restructuredtext/directives/components.py: Implementation of
!   document components directives 'contents', 'footnotes', etc.  Added
    to project.
  
  * restructuredtext/directives/images.py: Implementation of
!   directives 'image' & 'figure'.  Added to project.
  
  * restructuredtext/directives/html.py: Implementation of
!   HTML-specific directives 'meta' & 'imagemap'.  Added to project.
  
! * restructuredtext/languages: Subpackage added to project.  Contains
    modules for language-dependent language-dependent parser features.
    Includes en.py for English.
  
! * test: Subdirectory added.  The top-level consists of a modular test
    framework begun by Garth Kidd.
  
  * test/test_states: Subdirectory added; contains test modules
!   refactored from the old restructuredtext/test_states.py.
  
! * tools: Subdirectory added.  Contains quicktest.py by Garth Kidd, a
!   front-end to the reStructuredText parser; publish.py, a minimal
!   front-end to the Docutils Publisher producing pretty-printed
!   pseudo-XML; and html.py, a simple HTML-producing front-end.
  
! * sandbox: Subdirectory added; for playing around.  It's OK to make
    a mess!
  
***************
*** 197,200 ****
--- 178,183 ----
  * sandbox/alanj: Subdirectory added, from files by Alan Jaffray.
  
+ * sandbox/richardj: Subdirectory added, from files by Richard Jones.
+ 
  * spec/alternatives.txt: Added to project.
  
***************
*** 215,219 ****
    - Removed mention of compound enumerators.
    - Updated footnotes.
!   - Removed "Parser Implementation Plan". (It's implemented!)
    - Revised.
  
--- 198,202 ----
    - Removed mention of compound enumerators.
    - Updated footnotes.
!   - Removed "Parser Implementation Plan".  (It's implemented!)
    - Revised.
  
***************
*** 292,298 ****
  * restructuredtext/test_states.py: Added to project.
  
! * restructuredtext/ndiff.py: Added to project. This is a modified
    version of Python's Tools/scripts/ndiff.py, and is used by
!   test_states.py. I have committed to adding its functionality to
    Python's Lib/difflib.py.
  
--- 275,281 ----
  * restructuredtext/test_states.py: Added to project.
  
! * restructuredtext/ndiff.py: Added to project.  This is a modified
    version of Python's Tools/scripts/ndiff.py, and is used by
!   test_states.py.  I have committed to adding its functionality to
    Python's Lib/difflib.py.
  
***************
*** 300,304 ****
  
    - Introduced implicit hyperlink targets for section titles.
!   - Changed 'comment block' to 'explicit markup block'. Rearranged &
      edited the text of footnotes, hyperlink targets, directives, &
      comments.
--- 283,287 ----
  
    - Introduced implicit hyperlink targets for section titles.
!   - Changed 'comment block' to 'explicit markup block'.  Rearranged &
      edited the text of footnotes, hyperlink targets, directives, &
      comments.
***************
*** 318,322 ****
  * spec/reStructuredText.txt:
  
!   - Added workable indented section syntax, then removed it. See
      spec/indentedsections.txt (included in this release only).
    - Added details of whitespace preservation in inline literals.
--- 301,305 ----
  * spec/reStructuredText.txt:
  
!   - Added workable indented section syntax, then removed it.  See
      spec/indentedsections.txt (included in this release only).
    - Added details of whitespace preservation in inline literals.
***************
*** 353,357 ****
    - Tightened up syntax specifications.
    - Changed "descriptive lists" to "definition lists", changed syntax.
!   - Added field lists. Syntax not settled yet.
    - Added header row separator ('=') to tables.
    - Allowed comment blocks (comments, directives, hyperlink targets,
--- 336,340 ----
    - Tightened up syntax specifications.
    - Changed "descriptive lists" to "definition lists", changed syntax.
!   - Added field lists.  Syntax not settled yet.
    - Added header row separator ('=') to tables.
    - Allowed comment blocks (comments, directives, hyperlink targets,
***************
*** 371,375 ****
    - Added sections: "Blank Lines in Lists", "Definition List Markup",
      "Underlining".
!   - General editing & cleanup. Tightened up analyses, added
      alternatives.
  
--- 354,358 ----
    - Added sections: "Blank Lines in Lists", "Definition List Markup",
      "Underlining".
!   - General editing & cleanup.  Tightened up analyses, added
      alternatives.
  
***************
*** 393,399 ****
  
  
! .. Local Variables:
! .. mode: indented-text
! .. indent-tabs-mode: nil
! .. fill-column: 70
! .. End:
--- 376,384 ----
  
  
! ..
!    Local Variables:
!    mode: indented-text
!    indent-tabs-mode: nil
!    sentence-end-double-space: t
!    fill-column: 70
!    End:

[Structuredtext-checkins] CVS: restructuredtext/restructuredtext states.py,1.50,1.51

From: David G. <go...@us...> - 2002-04-18 02:46:54

Update of /cvsroot/structuredtext/restructuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv13726/restructuredtext/restructuredtext

Modified Files:
	states.py 
Log Message:
Fixed option list bug.

Index: states.py
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/restructuredtext/states.py,v
retrieving revision 1.50
retrieving revision 1.51
diff -C2 -d -r1.50 -r1.51
*** states.py	13 Apr 2002 16:43:53 -0000	1.50
--- states.py	18 Apr 2002 02:46:51 -0000	1.51
***************
*** 109,119 ****
  
  
- __all__ = ['RSTStateMachine', 'MarkupError', 'ParserError',
-            'TransformationError']
- 
- 
  class MarkupError(Exception): pass
  class ParserError(Exception): pass
- class TransformationError(Exception): pass
  
  
--- 109,114 ----
***************
*** 1056,1060 ****
          """Option list item."""
          optionlist = nodes.option_list()
-         self.statemachine.node += optionlist
          try:
              listitem, blankfinish = self.option_list_item(match)
--- 1051,1054 ----
***************
*** 1071,1074 ****
--- 1065,1069 ----
                  self.statemachine.node += self.unindentwarning()
              return [], nextstate, []
+         self.statemachine.node += optionlist
          optionlist += listitem
          offset = self.statemachine.lineoffset + 1   # next line
***************
*** 1087,1090 ****
--- 1082,1087 ----
          indented, indent, lineoffset, blankfinish = \
                self.statemachine.getfirstknownindented(match.end())
+         if not indented:                # not an option list item
+             raise statemachine.TransitionCorrection('text')
          option_group = nodes.option_group('', *options)
          description = nodes.description('\n'.join(indented))

[Structuredtext-checkins] CVS: restructuredtext/spec rst-notes.txt,1.41,1.42

From: David G. <go...@us...> - 2002-04-18 02:43:25

Update of /cvsroot/structuredtext/restructuredtext/spec
In directory usw-pr-cvs1:/tmp/cvs-serv12854/restructuredtext/spec

Modified Files:
	rst-notes.txt 
Log Message:
Fixed whitespace & updated

Index: rst-notes.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/spec/rst-notes.txt,v
retrieving revision 1.41
retrieving revision 1.42
diff -C2 -d -r1.41 -r1.42
*** rst-notes.txt	13 Apr 2002 16:27:04 -0000	1.41
--- rst-notes.txt	18 Apr 2002 02:43:22 -0000	1.42
***************
*** 26,30 ****
  
  - Create a standalone reStructuredText -> HTML/XML converter (stdin ->
!   stdout filter). (Flesh out tools/quicktest.py.)
  
  - Allow very long titles (on two or more lines)?
--- 26,30 ----
  
  - Create a standalone reStructuredText -> HTML/XML converter (stdin ->
!   stdout filter).  (Flesh out tools/quicktest.py.)
  
  - Allow very long titles (on two or more lines)?
***************
*** 33,48 ****
    allowed to be very long (two or more lines) also?
  
! - Allow hyperlink references to targets in other documents? Not in an
    HTML-centric way, though (it's trivial to say
    ``http://www.whatever.com/doc#name``, and useless in non-HTML
!   contexts).  XLink/XPointer? ``.. baseref::``? See Doc-SIG
    2001-08-10.
  
! - Add character processing? For example:
  
    - ``--`` -> em-dash (or ``--`` -> en-dash, and ``---`` -> em-dash).
      (Look for pre-existing conventions.)
!   - Convert quotes to curly quote entities. (Essentially impossible
!     for HTML?  Unnecessary for TeX. An output issue?)
    - Various forms of ``:-)`` to smiley icons.
    - ``"\ "`` -> &nbsp;.
--- 33,48 ----
    allowed to be very long (two or more lines) also?
  
! - Allow hyperlink references to targets in other documents?  Not in an
    HTML-centric way, though (it's trivial to say
    ``http://www.whatever.com/doc#name``, and useless in non-HTML
!   contexts).  XLink/XPointer?  ``.. baseref::``?  See Doc-SIG
    2001-08-10.
  
! - Add character processing?  For example:
  
    - ``--`` -> em-dash (or ``--`` -> en-dash, and ``---`` -> em-dash).
      (Look for pre-existing conventions.)
!   - Convert quotes to curly quote entities.  (Essentially impossible
!     for HTML?  Unnecessary for TeX.  An output issue?)
    - Various forms of ``:-)`` to smiley icons.
    - ``"\ "`` -> &nbsp;.
***************
*** 52,56 ****
    - Others?
  
!   How to represent character entities in the text though? Probably as
    Unicode.
  
--- 52,56 ----
    - Others?
  
!   How to represent character entities in the text though?  Probably as
    Unicode.
  
***************
*** 58,66 ****
    the writer?
  
! - Implement the header row separator modification to table.el. (Wrote
!   to Takaaki Ota & the table.el mailing list on 2001-08-12,
!   suggesting support for '=====' header rows. On 2001-08-17 he
!   replied, saying he'd put it on his to-do list, but don't hold your
!   breath.)
  
  - Tony says inline markup rule 7 could do with a *little* more
--- 58,65 ----
    the writer?
  
! - Implement the header row separator modification to table.el.  (Wrote
!   to Takaaki Ota & the table.el mailing list on 2001-08-12, suggesting
!   support for '=====' header rows.  On 2001-08-17 he replied, saying
!   he'd put it on his to-do list, but "don't hold your breath".)
  
  - Tony says inline markup rule 7 could do with a *little* more
***************
*** 80,85 ****
  
  - Tighten up the spec for indentation of "constructs using complex
!   markers": field lists and option lists? Bodies may begin on the same
!   line as the marker or on a subsequent line (with blank lines
    optional).  Require that for bodies beginning on the same line as
    the marker, all lines be in strict alignment.  Currently, this is
--- 79,84 ----
  
  - Tighten up the spec for indentation of "constructs using complex
!   markers": field lists and option lists?  Bodies may begin on the
!   same line as the marker or on a subsequent line (with blank lines
    optional).  Require that for bodies beginning on the same line as
    the marker, all lines be in strict alignment.  Currently, this is
***************
*** 90,94 ****
  
    This proposal would make the above example illegal, instead
!   requiring strict alignment. A field body may either begin on the
    same line::
  
--- 89,93 ----
  
    This proposal would make the above example illegal, instead
!   requiring strict alignment.  A field body may either begin on the
    same line::
  
***************
*** 116,136 ****
      numbering; add support to .contents; could be cmdline option also)
  
!   - misc.raw, .include (``#include`` one file in another; but how to
!     parse wrt sections, reference names, conflicts?), .exec
!     (execute Python code & insert the results; dangerous?), .eval
!     (evaluate an expression & insert the text; at parse time or
!     substitution time?)
  
!   - block.qa (Questions & Answers; implement as a generic two-column
!     marked list?)
  
!   - colorize.python (Colorize Python code.  Fine for HTML output, what
!     about other formats?  Revert to a literal block?  Do we need some
!     kind of "alternate" mechanism?  Perhaps use a "pending" transform,
!     which could switch its output based on the "format" in use.  Use a
!     factory function "transformFF()" which returns either
!     "HTMLTransform()" instance or "GenericTransform" instance?)
  
!   - text.date (for substitutions)
  
      - Combined with misc.include, implement canned macros?
--- 115,143 ----
      numbering; add support to .contents; could be cmdline option also)
  
!   - misc.raw
  
!   - misc.include: ``#include`` one file in another.  But how to
!     parse wrt sections, reference names, conflicts?
  
!   - misc.exec: Execute Python code & insert the results.  Perhaps
!     dangerous?
  
!   - misc.eval: Evaluate an expression & insert the text.  At parse
!     time or at substitution time?
! 
!   - block.qa: Questions & Answers.  Implement as a generic two-column
!     marked list?  Or as a standalone construct?
! 
!   - block.columns: Multi-column table/list, with number of columns as
!     argument.
! 
!   - colorize.python: Colorize Python code.  Fine for HTML output, but
!     what about other formats?  Revert to a literal block?  Do we need
!     some kind of "alternate" mechanism?  Perhaps use a "pending"
!     transform, which could switch its output based on the "format" in
!     use.  Use a factory function "transformFF()" which returns either
!     "HTMLTransform()" instance or "GenericTransform" instance?
! 
!   - text.date: Datestamp.  For substitutions.
  
      - Combined with misc.include, implement canned macros?
***************
*** 140,149 ****
  - Use the language module for directive attribute names?
  
  - Allow syntax constructs to be added or disabled at run-time.
  
! - Make footnotes two-way, GNU-style? What if there are multiple
    references to a single footnote?
  
! - Add RFC-822 header parsing (for PEP, email Readers).
  
  - Change ``.. meta::`` to use a "pending" element, only activated for
--- 147,158 ----
  - Use the language module for directive attribute names?
  
+ - Add more attributes to the image directive: align, border?
+ 
  - Allow syntax constructs to be added or disabled at run-time.
  
! - Make footnotes two-way, GNU-style?  What if there are multiple
    references to a single footnote?
  
! - Add RFC-2822 header parsing (for PEP, email Readers).
  
  - Change ``.. meta::`` to use a "pending" element, only activated for
***************
*** 169,183 ****
       construct, such as a literal block?
  
!   Both could be solved using empty comments (#2 already exists for a
!   block quote after a literal block).  But that's a hack.
  
    See the Doc-SIG discussion starting 2001-04-18 with Ed Loper's
    "Structuring: a summary; and an attempt at EBNF", item 4.
  
  
  Or Not To Do?
  =============
  
! This is the realm of the possible but questionably probable. These
  ideas are kept here as a record of what has been proposed, for
  posterity and in case any of them prove to be useful.
--- 178,206 ----
       construct, such as a literal block?
  
!   Both could be solved using empty comments (problem 2 already exists
!   for a block quote after a literal block).  But that's a hack.
  
    See the Doc-SIG discussion starting 2001-04-18 with Ed Loper's
    "Structuring: a summary; and an attempt at EBNF", item 4.
  
+ - Add a "verse" construct, for paragraphs with linebreaks preserved?
+   A directive would be easy; what about a literal-block-like prefix,
+   perhaps ';;'?  E.g.::
+ 
+       Take it away, Eric the orchestra leader!  ;;
+ 
+           Half a bee,
+           Philosophically,
+           Must ipso-facto
+           Half not be.
+           You see?
+ 
+           ...
+ 
  
  Or Not To Do?
  =============
  
! This is the realm of the possible but questionably probable.  These
  ideas are kept here as a record of what has been proposed, for
  posterity and in case any of them prove to be useful.
***************
*** 188,193 ****
  
  (A future revision of this specification may allow for compound
! enumerators, such as '1.a.' or '1(a)', to allow for nested enumerated
! lists without indentation.)
  
  
--- 211,216 ----
  
  (A future revision of this specification may allow for compound
! enumerators, such as '1.1.' or '1.a.' or '1(a)', to allow for nested
! enumerated lists without indentation.)
  
  
***************
*** 195,199 ****
  ------------------------------
  
! Add these? Example::
  
      #. Item 1.
--- 218,222 ----
  ------------------------------
  
! Add these?  Example::
  
      #. Item 1.
***************
*** 201,205 ****
      #. Item 3.
  
! Arabic numerals only, or any sequence if first initialized? For
  example::
  
--- 224,228 ----
      #. Item 3.
  
! Arabic numerals only, or any sequence if first initialized?  For
  example::
  
***************
*** 209,228 ****
  
  
- Two-For-One Literal Blocks
- --------------------------
- 
- [Aside: One possible variation is for meta-documentation (perhaps an
- extension?): use triple-colons (':::') or a directive ('..
- literal-parsed::') to indicate 'take the following literal block, mark
- it up as a literal block, then copy it and mark it up as if it weren't
- a literal block'.  The implementation may insert text in-between, such
- as 'Marked up as:', or may alter the formatting (different font, set
- in a colored box, whatever).]
- 
- 
  Sloppy Indentation of List Items
  --------------------------------
  
! Perhaps the indentation shouldn't be so strict. Currently, this is
  required::
  
--- 232,239 ----
  
  
  Sloppy Indentation of List Items
  --------------------------------
  
! Perhaps the indentation shouldn't be so strict.  Currently, this is
  required::
  
***************
*** 239,243 ****
      1. First para.
  
!        Block quote. (no good: requires some indent relative to first
         para)
  
--- 250,254 ----
      1. First para.
  
!        Block quote.  (no good: requires some indent relative to first
         para)
  
***************
*** 250,254 ****
         Literal block?
  
! Hmm... Non-strict indentation isn't such a good idea.
  
  
--- 261,265 ----
         Literal block?
  
! Hmm...  Non-strict indentation isn't such a good idea.
  
  
***************
*** 264,272 ****
  
  Change that to *require* a blank line above and below, to reduce
! ambiguity. This "loosening" may be added later, once the parser's been
! nailed down. However, a serious drawback of this approach is to limit
! the content of each list item to a single paragraph. Garth Kidd is
! attempting to work out a consistent set of rules for "lazy
! indentation".
  
  
--- 275,281 ----
  
  Change that to *require* a blank line above and below, to reduce
! ambiguity.  This "loosening" may be added later, once the parser's
! been nailed down.  However, a serious drawback of this approach is to
! limit the content of each list item to a single paragraph.
  
  
***************
*** 274,287 ****
  `````````````````````````````````
  
! Consider a paragraph in a word processor. It is a single logical line
  of text which ends with a newline, soft-wrapped arbitrarily at the
! right edge of the page or screen. We can think of a plaintext
  paragraph in the same way, as a single logical line of text, ending
  with two newlines (a blank line) instead of one, and which may contain
  arbitrary line breaks (newlines) where it was accidentally
! hard-wrapped by an application. We can compensate for the accidental
  hard-wrapping by "unwrapping" every unindented second and subsequent
! line. The indentation of the first line of a paragraph or list item
! would determine the indentation for the entire element. Blank lines
  would be required between list items when using lazy indentation.
  
--- 283,296 ----
  `````````````````````````````````
  
! Consider a paragraph in a word processor.  It is a single logical line
  of text which ends with a newline, soft-wrapped arbitrarily at the
! right edge of the page or screen.  We can think of a plaintext
  paragraph in the same way, as a single logical line of text, ending
  with two newlines (a blank line) instead of one, and which may contain
  arbitrary line breaks (newlines) where it was accidentally
! hard-wrapped by an application.  We can compensate for the accidental
  hard-wrapping by "unwrapping" every unindented second and subsequent
! line.  The indentation of the first line of a paragraph or list item
! would determine the indentation for the entire element.  Blank lines
  would be required between list items when using lazy indentation.
  
***************
*** 309,318 ****
  
        Term
!           Definition. The indentation of the term is
      required, as is the indentation of the definition's
      first line.
  
            When the definition extends to more than
!     one line, lazy indentation may occur. (This is the second
      paragraph of the definition.)
  
--- 318,327 ----
  
        Term
!           Definition.  The indentation of the term is
      required, as is the indentation of the definition's
      first line.
  
            When the definition extends to more than
!     one line, lazy indentation may occur.  (This is the second
      paragraph of the definition.)
  
***************
*** 341,347 ****
  
  Literal blocks and block quotes would still require consistent
! indentation for all their lines. For block quotes, we might be able to
! get away with only requiring that the first line of each contained
! element be indented. For example::
  
      Here's a paragraph.
--- 350,356 ----
  
  Literal blocks and block quotes would still require consistent
! indentation for all their lines.  For block quotes, we might be able
! to get away with only requiring that the first line of each contained
! element be indented.  For example::
  
      Here's a paragraph.
***************
*** 356,364 ****
      bullet list inside the block quote.
  
! Although feasible, this form of lazy indentation has problems. The
  document structure and hierarchy is not obvious from the indentation,
! making the source plaintext difficult to read. This will also make
  keeping track of the indentation while writing difficult and
! error-prone. However, these problems may be acceptable for Wikis and
  email mode, where we may be able to rely on less complex structure
  (few nested lists, for example).
--- 365,373 ----
      bullet list inside the block quote.
  
! Although feasible, this form of lazy indentation has problems.  The
  document structure and hierarchy is not obvious from the indentation,
! making the source plaintext difficult to read.  This will also make
  keeping track of the indentation while writing difficult and
! error-prone.  However, these problems may be acceptable for Wikis and
  email mode, where we may be able to rely on less complex structure
  (few nested lists, for example).

[Structuredtext-checkins] CVS: restructuredtext setup.py,1.6,1.7

From: David G. <go...@us...> - 2002-04-18 02:43:23

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv12841/restructuredtext

Modified Files:
	setup.py 
Log Message:
version 0.4

Index: setup.py
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/setup.py,v
retrieving revision 1.6
retrieving revision 1.7
diff -C2 -d -r1.6 -r1.7
*** setup.py	7 Mar 2002 03:44:59 -0000	1.6
--- setup.py	18 Apr 2002 02:43:20 -0000	1.7
***************
*** 10,14 ****
            #long_description = '',
            url = 'http://structuredtext.sourceforge.net/',
!           version = '0.3+',
            author = 'David Goodger',
            author_email = 'go...@us...',
--- 10,14 ----
            #long_description = '',
            url = 'http://structuredtext.sourceforge.net/',
!           version = '0.4',
            author = 'David Goodger',
            author_email = 'go...@us...',

[Structuredtext-checkins] CVS: restructuredtext/spec reStructuredText.txt,1.46,1.47

From: David G. <go...@us...> - 2002-04-18 02:43:17

Update of /cvsroot/structuredtext/restructuredtext/spec
In directory usw-pr-cvs1:/tmp/cvs-serv12777/restructuredtext/spec

Modified Files:
	reStructuredText.txt 
Log Message:
Fixed whitespace & updated

Index: reStructuredText.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/spec/reStructuredText.txt,v
retrieving revision 1.46
retrieving revision 1.47
diff -C2 -d -r1.46 -r1.47
*** reStructuredText.txt	13 Apr 2002 16:42:47 -0000	1.46
--- reStructuredText.txt	18 Apr 2002 02:43:13 -0000	1.47
***************
*** 8,22 ****
  
  reStructuredText_ is plain text that uses simple and intuitive
! constructs to indicate the structure of a document. These constructs
! are equally easy to read in raw and processed forms. This document is
  itself an example of reStructuredText (raw, if you are reading the
  text file, or processed, if you are reading an HTML document, for
! example). reStructuredText is a candidate markup syntax for the
  `Python Docstring Processing System`_.
  
  Simple, implicit markup is used to indicate special constructs, such
[...1759 lines suppressed...]
  
! .. [#URI] Uniform Resource Identifier.  URIs are a general form of
!    URLs (Uniform Resource Locators).  For the syntax of URIs see
!    RFC2396_ and RFC2732_.
  
  
***************
*** 2317,2321 ****
  .. _doctest module:
     http://www.python.org/doc/current/lib/module-doctest.html
! .. _getopt.py: http://www.python.org/doc/current/lib/module-getopt.html
  .. _GNU libc getopt_long():
     http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_516.html
--- 2319,2324 ----
  .. _doctest module:
     http://www.python.org/doc/current/lib/module-doctest.html
! .. _getopt.py:
!    http://www.python.org/doc/current/lib/module-getopt.html
  .. _GNU libc getopt_long():
     http://www.gnu.org/manual/glibc-2.2.3/html_node/libc_516.html

[Structuredtext-checkins] CVS: restructuredtext/spec problems.txt,1.7,1.8

From: David G. <go...@us...> - 2002-04-18 02:42:59

Update of /cvsroot/structuredtext/restructuredtext/spec
In directory usw-pr-cvs1:/tmp/cvs-serv12674/restructuredtext/spec

Modified Files:
	problems.txt 
Log Message:
Fixed whitespace & updated

Index: problems.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/spec/problems.txt,v
retrieving revision 1.7
retrieving revision 1.8
diff -C2 -d -r1.7 -r1.8
*** problems.txt	28 Mar 2002 04:27:44 -0000	1.7
--- problems.txt	18 Apr 2002 02:42:56 -0000	1.8
***************
*** 8,12 ****
  
  There are several problems, unresolved issues, and areas of
! controversy within StructuredText_ (Classic and Next Generation). In
  order to resolve all these issues, this analysis brings all of the
  issues out into the open, enumerates all the alternatives, and
--- 8,12 ----
  
  There are several problems, unresolved issues, and areas of
! controversy within StructuredText_ (Classic and Next Generation).  In
  order to resolve all these issues, this analysis brings all of the
  issues out into the open, enumerates all the alternatives, and
***************
*** 14,18 ****
  specification.
  
! 1. No `formal specification`_. The code *is* the standard.
  2. `Understanding and extending the code`_ is difficult.
  3. `Section structure via indentation`_.
--- 14,18 ----
  specification.
  
! 1. No `formal specification`_.  The code *is* the standard.
  2. `Understanding and extending the code`_ is difficult.
  3. `Section structure via indentation`_.
***************
*** 34,45 ****
  
  The description in the original StructuredText.py has been criticized
! for being vague. For practical purposes, "the code *is* the spec."
  Tony Ibbs has been working on deducing a `detailed description`_ from
! the documentation and code of StructuredTextNG_. Edward Loper's
  STMinus_ is another attempt to formalize a spec.
  
  For this kind of a project, the specification should always precede
! the code. Otherwise, the markup is a moving target which can never be
! adopted as a standard. Of course, a specification may be revised
  during lifetime of the code, but without a spec there is no visible
  control and thus no confidence.
--- 34,45 ----
  
  The description in the original StructuredText.py has been criticized
! for being vague.  For practical purposes, "the code *is* the spec."
  Tony Ibbs has been working on deducing a `detailed description`_ from
! the documentation and code of StructuredTextNG_.  Edward Loper's
  STMinus_ is another attempt to formalize a spec.
  
  For this kind of a project, the specification should always precede
! the code.  Otherwise, the markup is a moving target which can never be
! adopted as a standard.  Of course, a specification may be revised
  during lifetime of the code, but without a spec there is no visible
  control and thus no confidence.
***************
*** 50,55 ****
  
  The original StructuredText_ is a dense mass of sparsely commented
! code and inscrutable regular expressions. It was not designed to be
! extended and is very difficult to understand. StructuredTextNG_ has
  been designed to allow input (syntax) and output extensions, but its
  documentation (both internal [comments & docstrings], and external) is
--- 50,55 ----
  
  The original StructuredText_ is a dense mass of sparsely commented
! code and inscrutable regular expressions.  It was not designed to be
! extended and is very difficult to understand.  StructuredTextNG_ has
  been designed to allow input (syntax) and output extensions, but its
  documentation (both internal [comments & docstrings], and external) is
***************
*** 58,62 ****
  For reStructuredText to become truly useful, perhaps even part of
  Python's standard library, it must have clear, understandable
! documentation and implementation code. For the implementation of
  reStructuredText to be taken seriously, it must be a sterling example
  of the potential of docstrings; the implementation must practice what
--- 58,62 ----
  For reStructuredText to become truly useful, perhaps even part of
  Python's standard library, it must have clear, understandable
! documentation and implementation code.  For the implementation of
  reStructuredText to be taken seriously, it must be a sterling example
  of the potential of docstrings; the implementation must practice what
***************
*** 67,79 ****
  =================================
  
! Setext_ required that body text be indented by 2 spaces. The original
  StructuredText_ and StructuredTextNG_ require that section structure
! be indicated through indentation, as "inspired by Python". For certain
! structures with a very limited, local extent (such as lists, block
! quotes, and literal blocks), indentation naturally indicates structure
! or hierarchy. For sections (which may have a very large extent),
! structure via indentation is unnecessary, unnatural and ambiguous.
! Rather, the syntax of the section title *itself* should indicate that
! it is a section title.
  
  The original StructuredText states that "A single-line paragraph whose
--- 67,79 ----
  =================================
  
! Setext_ required that body text be indented by 2 spaces.  The original
  StructuredText_ and StructuredTextNG_ require that section structure
! be indicated through indentation, as "inspired by Python".  For
! certain structures with a very limited, local extent (such as lists,
! block quotes, and literal blocks), indentation naturally indicates
! structure or hierarchy.  For sections (which may have a very large
! extent), structure via indentation is unnecessary, unnatural and
! ambiguous.  Rather, the syntax of the section title *itself* should
! indicate that it is a section title.
  
  The original StructuredText states that "A single-line paragraph whose
***************
*** 81,98 ****
  header." Requiring indentation in this way is:
  
! - Unnecessary. The vast majority of docstrings and standalone
    documents will have no more than one level of section structure.
    Requiring indentation for such docstrings is unnecessary and
    irritating.
  
! - Unnatural. Most published works use title style (type size, face,
    weight, and position) and/or section/subsection numbering rather
!   than indentation to indicate hierarchy. This is a tradition with a
    very long history.
  
! - Ambiguous. A StructuredText header is indistinguishable from a
    one-line paragraph followed by a block quote (precluding the use of
!   block quotes). Enumerated section titles are ambiguous (is it a
!   header? is it a list item?). Some additional adornment must be
    required to confirm the line's role as a title, both to a parser and
    to the human reader of the source text.
--- 81,98 ----
  header." Requiring indentation in this way is:
  
! - Unnecessary.  The vast majority of docstrings and standalone
    documents will have no more than one level of section structure.
    Requiring indentation for such docstrings is unnecessary and
    irritating.
  
! - Unnatural.  Most published works use title style (type size, face,
    weight, and position) and/or section/subsection numbering rather
!   than indentation to indicate hierarchy.  This is a tradition with a
    very long history.
  
! - Ambiguous.  A StructuredText header is indistinguishable from a
    one-line paragraph followed by a block quote (precluding the use of
!   block quotes).  Enumerated section titles are ambiguous (is it a
!   header? is it a list item?).  Some additional adornment must be
    required to confirm the line's role as a title, both to a parser and
    to the human reader of the source text.
***************
*** 103,108 ****
  
  reStructuredText_ indicates section structure through title adornment
! style (as exemplified by this document). This is far more natural. In
! fact, it is already in widespread use in plain text documents,
  including in Python's standard distribution (such as the toplevel
  README_ file).
--- 103,108 ----
  
  reStructuredText_ indicates section structure through title adornment
! style (as exemplified by this document).  This is far more natural.
! In fact, it is already in widespread use in plain text documents,
  including in Python's standard distribution (such as the toplevel
  README_ file).
***************
*** 114,127 ****
  No matter what characters are chosen for markup, some day someone will
  want to write documentation *about* that markup or using markup
! characters in a non-markup context. Therefore, any complete markup
! language must have an escaping or encoding mechanism. For a
  lightweight markup system, encoding mechanisms like SGML/XML's '&ast;'
! are out. So an escaping mechanism is in. However, with carefully
  chosen markup, it should be necessary to use the escaping mechanism
  only infrequently.
  
  reStructuredText_ needs an escaping mechanism: a way to treat
! markup-significant characters as the characters themselves. Currently
! there is no such mechanism (although ZWiki uses '!'). What are the
  candidates?
  
--- 114,127 ----
  No matter what characters are chosen for markup, some day someone will
  want to write documentation *about* that markup or using markup
! characters in a non-markup context.  Therefore, any complete markup
! language must have an escaping or encoding mechanism.  For a
  lightweight markup system, encoding mechanisms like SGML/XML's '&ast;'
! are out.  So an escaping mechanism is in.  However, with carefully
  chosen markup, it should be necessary to use the escaping mechanism
  only infrequently.
  
  reStructuredText_ needs an escaping mechanism: a way to treat
! markup-significant characters as the characters themselves.  Currently
! there is no such mechanism (although ZWiki uses '!').  What are the
  candidates?
  
***************
*** 131,142 ****
  4. doubling of characters
  
! The best choice for this is the backslash (``\``). It's "the single
  most popular escaping character in the world!", therefore familiar and
! unsurprising. Since characters only need to be escaped under special
  circumstances, which are typically those explaining technical
  programming issues, the use of the backslash is natural and
! understandable. Python docstrings can be raw (prefixed with an 'r', as
! in 'r""'), which would obviate the need for gratuitous doubling-up of
! backslashes.
  
  (On 2001-03-29 on the Doc-SIG mailing list, GvR endorsed backslash
--- 131,142 ----
  4. doubling of characters
  
! The best choice for this is the backslash (``\``).  It's "the single
  most popular escaping character in the world!", therefore familiar and
! unsurprising.  Since characters only need to be escaped under special
  circumstances, which are typically those explaining technical
  programming issues, the use of the backslash is natural and
! understandable.  Python docstrings can be raw (prefixed with an 'r',
! as in 'r""'), which would obviate the need for gratuitous doubling-up
! of backslashes.
  
  (On 2001-03-29 on the Doc-SIG mailing list, GvR endorsed backslash
***************
*** 146,152 ****
  
  The rule would be: An unescaped backslash followed by any markup
! character escapes the character. The escaped character represents the
  character itself, and is prevented from playing a role in any markup
! interpretation. The backslash is removed from the output. A literal
  backslash is represented by an "escaped backslash," two backslashes in
  a row.
--- 146,152 ----
  
  The rule would be: An unescaped backslash followed by any markup
! character escapes the character.  The escaped character represents the
  character itself, and is prevented from playing a role in any markup
! interpretation.  The backslash is removed from the output.  A literal
  backslash is represented by an "escaped backslash," two backslashes in
  a row.
***************
*** 158,168 ****
  When an expression (requiring backslashes and other characters used
  for markup) becomes too complicated and therefore unreadable, a
! literal block may be used instead. Inside literal blocks, no markup is
! recognized, therefore backslashes (for the purpose of escaping markup)
! become unnecessary.
  
  We could allow backslashes preceding non-markup characters to remain
! in the output. This would make describing regular expressions and
! other uses of backslashes easier. However, this would complicate the
  markup rules and would be confusing.
  
--- 158,168 ----
  When an expression (requiring backslashes and other characters used
  for markup) becomes too complicated and therefore unreadable, a
! literal block may be used instead.  Inside literal blocks, no markup
! is recognized, therefore backslashes (for the purpose of escaping
! markup) become unnecessary.
  
  We could allow backslashes preceding non-markup characters to remain
! in the output.  This would make describing regular expressions and
! other uses of backslashes easier.  However, this would complicate the
  markup rules and would be confusing.
  
***************
*** 173,177 ****
  Oft-requested in Doc-SIG (the earliest reference is dated 1996-08-13)
  is the ability to write lists without requiring blank lines between
! items. In docstrings, space is at a premium. Authors want to convey
  their API or usage information in as compact a form as possible.
  StructuredText_ requires blank lines between all body elements,
--- 173,177 ----
  Oft-requested in Doc-SIG (the earliest reference is dated 1996-08-13)
  is the ability to write lists without requiring blank lines between
! items.  In docstrings, space is at a premium.  Authors want to convey
  their API or usage information in as compact a form as possible.
  StructuredText_ requires blank lines between all body elements,
***************
*** 181,185 ****
  In reStructuredText, blank lines are optional between list items.
  However, in order to eliminate ambiguity, a blank line is required
! before the first list item and after the last. Nested lists also
  require blank lines before the list start and after the list end.
  
--- 181,185 ----
  In reStructuredText, blank lines are optional between list items.
  However, in order to eliminate ambiguity, a blank line is required
! before the first list item and after the last.  Nested lists also
  require blank lines before the list start and after the list end.
  
***************
*** 188,194 ****
  ==================
  
! StructuredText_ includes 'o' as a bullet character. This is dangerous
! and counter to the language-independent nature of the markup. There
! are many languages in which 'o' is a word. For example, in Spanish::
  
      Llamame a la casa
--- 188,194 ----
  ==================
  
! StructuredText_ includes 'o' as a bullet character.  This is dangerous
! and counter to the language-independent nature of the markup.  There
! are many languages in which 'o' is a word.  For example, in Spanish::
  
      Llamame a la casa
***************
*** 208,213 ****
  could be misinterpreted as a bullet list.
  
! In reStructuredText_, 'o' is not used as a bullet character. '-', '*',
! and '+' are the possible bullet characters.
  
  
--- 208,213 ----
  could be misinterpreted as a bullet list.
  
! In reStructuredText_, 'o' is not used as a bullet character.  '-',
! '*', and '+' are the possible bullet characters.
  
  
***************
*** 217,226 ****
  StructuredText enumerated lists are allowed to begin with numbers and
  letters followed by a period or right-parenthesis, then whitespace.
! This has surprising consequences for writing styles. For example, this
! is recognized as an enumerated list item by StructuredText::
  
      Mr. Creosote.
  
! People will write enumerated lists in all different ways. It is folly
  to try to come up with the "perfect" format for an enumerated list,
  and limit the docstring parser's recognition to that one format only.
--- 217,226 ----
  StructuredText enumerated lists are allowed to begin with numbers and
  letters followed by a period or right-parenthesis, then whitespace.
! This has surprising consequences for writing styles.  For example,
! this is recognized as an enumerated list item by StructuredText::
  
      Mr. Creosote.
  
! People will write enumerated lists in all different ways.  It is folly
  to try to come up with the "perfect" format for an enumerated list,
  and limit the docstring parser's recognition to that one format only.
***************
*** 232,237 ****
  
  If a PELI is labeled with a "1.", and is immediately followed by a
! PELI labeled with a "2.", we've got an enumerated list. Or "(A)"
! followed by "(B)". Or "i)" followed by "ii)", etc. The chances of
  accidentally recognizing two adjacent and consistently labeled PELIs,
  are acceptably small.
--- 232,237 ----
  
  If a PELI is labeled with a "1.", and is immediately followed by a
! PELI labeled with a "2.", we've got an enumerated list.  Or "(A)"
! followed by "(B)".  Or "i)" followed by "ii)", etc.  The chances of
  accidentally recognizing two adjacent and consistently labeled PELIs,
  are acceptably small.
***************
*** 252,261 ****
  
  StructuredText uses ' -- ' (whitespace, two hyphens, whitespace) on
! the first line of a paragraph to indicate a definition list item. The
  ' -- ' serves to separate the term (on the left) from the definition
  (on the right).
  
  Many people use ' -- ' as an em-dash in their text, conflicting with
! the StructuredText usage. Although the Chicago Manual of Style says
  that spaces should not be used around an em-dash, Peter Funk pointed
  out that this is standard usage in German (according to the Duden, the
--- 252,261 ----
  
  StructuredText uses ' -- ' (whitespace, two hyphens, whitespace) on
! the first line of a paragraph to indicate a definition list item.  The
  ' -- ' serves to separate the term (on the left) from the definition
  (on the right).
  
  Many people use ' -- ' as an em-dash in their text, conflicting with
! the StructuredText usage.  Although the Chicago Manual of Style says
  that spaces should not be used around an em-dash, Peter Funk pointed
  out that this is standard usage in German (according to the Duden, the
***************
*** 277,283 ****
  
  A reStructuredText definition list item consists of a term and a
! definition. A term is a simple one-line paragraph. A definition is a
  block indented relative to the term, and may contain multiple
! paragraphs and other body elements. No blank line precedes a
  definition (this distinguishes definition lists from block quotes).
  
--- 277,283 ----
  
  A reStructuredText definition list item consists of a term and a
! definition.  A term is a simple one-line paragraph.  A definition is a
  block indented relative to the term, and may contain multiple
! paragraphs and other body elements.  No blank line precedes a
  definition (this distinguishes definition lists from block quotes).
  
***************
*** 286,300 ****
  ==============
  The StructuredText_ specification has literal blocks indicated by
! 'example', 'examples', or '::' ending the preceding paragraph. STNG
! only recognizes '::'; 'example'/'examples' are not implemented. This
! is good; it fixes an unnecessary language dependency. The problem is
  what to do with the sometimes- unwanted '::'.
  
  In reStructuredText_ '::' at the end of a paragraph indicates that
! subsequent *indented* blocks are treated as literal text. No further
  markup interpretation is done within literal blocks (not even
! backslash-escapes). If the '::' is preceded by whitespace, '::' is
  omitted from the output; if '::' was the sole content of a paragraph,
! the entire paragraph is removed (no 'empty' paragraph remains). If
  '::' is preceded by a non-whitespace character, '::' is replaced by
  ':' (i.e., the extra colon is removed).
--- 286,300 ----
  ==============
  The StructuredText_ specification has literal blocks indicated by
! 'example', 'examples', or '::' ending the preceding paragraph.  STNG
! only recognizes '::'; 'example'/'examples' are not implemented.  This
! is good; it fixes an unnecessary language dependency.  The problem is
  what to do with the sometimes- unwanted '::'.
  
  In reStructuredText_ '::' at the end of a paragraph indicates that
! subsequent *indented* blocks are treated as literal text.  No further
  markup interpretation is done within literal blocks (not even
! backslash-escapes).  If the '::' is preceded by whitespace, '::' is
  omitted from the output; if '::' was the sole content of a paragraph,
! the entire paragraph is removed (no 'empty' paragraph remains).  If
  '::' is preceded by a non-whitespace character, '::' is replaced by
  ':' (i.e., the extra colon is removed).
***************
*** 313,322 ****
  ======
  
! The table markup scheme in classic StructuredText was horrible. Its
  omission from StructuredTextNG is welcome, and its markup will not be
! repeated here. However, tables themselves are useful in documentation.
! Alternatives:
  
! 1. This format is the most natural and obvious. It was independently
     invented (no great feat of creation!), and later found to be the
     format supported by the `Emacs table mode`_::
--- 313,322 ----
  ======
  
! The table markup scheme in classic StructuredText was horrible.  Its
  omission from StructuredTextNG is welcome, and its markup will not be
! repeated here.  However, tables themselves are useful in
! documentation.  Alternatives:
  
! 1. This format is the most natural and obvious.  It was independently
     invented (no great feat of creation!), and later found to be the
     format supported by the `Emacs table mode`_::
***************
*** 345,358 ****
  
     Row and column spans are possible simply by omitting the column or
!    row separators, respectively. The header row separator must be
     complete; in other words, a header cell may not span into the table
!    body. Each cell contains body elements, and may have multiple
!    paragraphs, lists, etc. Initial spaces for a left margin are
     allowed; the first line of text in a cell determines its left
     margin.
  
! 2. Below is a minimalist possibility. It may be better suited to
     manual input than alternative #1, but there is no Emacs editing
!    mode available. One disadvantage is that it resembles section
     titles; a one-column table would look exactly like section &
     subsection titles. ::
--- 345,358 ----
  
     Row and column spans are possible simply by omitting the column or
!    row separators, respectively.  The header row separator must be
     complete; in other words, a header cell may not span into the table
!    body.  Each cell contains body elements, and may have multiple
!    paragraphs, lists, etc.  Initial spaces for a left margin are
     allowed; the first line of text in a cell determines its left
     margin.
  
! 2. Below is a minimalist possibility.  It may be better suited to
     manual input than alternative #1, but there is no Emacs editing
!    mode available.  One disadvantage is that it resembles section
     titles; a one-column table would look exactly like section &
     subsection titles. ::
***************
*** 369,379 ****
  
     The table begins with a top border of equals signs with a space at
!    each column boundary (regardless of spans). Each row is underlined.
!    Internal row separators are underlines of '-', with spaces at
!    column boundaries. The last of the optional head rows is underlined
!    with '=', again with spaces at column boundaries. Column spans have
!    no spaces in their underline. Row spans simply lack an underline at
!    the row boundary. The bottom boundary of the table consists of '='
!    underlines. A blank line is required following a table.
  
  Alternative #1 is the choice adopted by reStructuredText.
--- 369,380 ----
  
     The table begins with a top border of equals signs with a space at
!    each column boundary (regardless of spans).  Each row is
!    underlined.  Internal row separators are underlines of '-', with
!    spaces at column boundaries.  The last of the optional head rows is
!    underlined with '=', again with spaces at column boundaries.
!    Column spans have no spaces in their underline.  Row spans simply
!    lack an underline at the row boundary.  The bottom boundary of the
!    table consists of '=' underlines.  A blank line is required
!    following a table.
  
  Alternative #1 is the choice adopted by reStructuredText.
***************
*** 387,399 ****
  emphatic text::
  
!     "**What?**" she cried. (*exit stage left*)
  
  The `reStructuredText markup specification`_ allows for such
  constructs and disambiguates inline markup through a set of
! recognition rules. These recognition rules define the context of
  markup start-strings and end-strings, allowing markup characters to be
  used in most non-markup contexts without a problem (or a backslash).
  So we can say, "Use asterisks (*) around words or phrases to
! *emphasisze* them." The '(*)' will not be recognized as markup. This
  reduces the need for markup escaping to the point where an escape
  character is *almost* (but not quite!) unnecessary.
--- 388,400 ----
  emphatic text::
  
!     "**What?**" she cried.  (*exit stage left*)
  
  The `reStructuredText markup specification`_ allows for such
  constructs and disambiguates inline markup through a set of
! recognition rules.  These recognition rules define the context of
  markup start-strings and end-strings, allowing markup characters to be
  used in most non-markup contexts without a problem (or a backslash).
  So we can say, "Use asterisks (*) around words or phrases to
! *emphasisze* them." The '(*)' will not be recognized as markup.  This
  reduces the need for markup escaping to the point where an escape
  character is *almost* (but not quite!) unnecessary.
***************
*** 403,407 ****
  ===========
  
! StructuredText uses '_text_' to indicate underlining. To quote David
  Ascher in his 2000-01-21 Doc-SIG mailing list post, "Docstring
  grammar: a very revised proposal":
--- 404,408 ----
  ===========
  
! StructuredText uses '_text_' to indicate underlining.  To quote David
  Ascher in his 2000-01-21 Doc-SIG mailing list post, "Docstring
  grammar: a very revised proposal":
***************
*** 417,421 ****
      ('__init__'), I think of docstring markups much like I think of
      type annotations -- they should be optional and above all do no
!     harm. In this case the underline markup does harm.
  
  Underlining is not part of the reStructuredText specification.
--- 418,422 ----
      ('__init__'), I think of docstring markups much like I think of
      type annotations -- they should be optional and above all do no
!     harm.  In this case the underline markup does harm.
  
  Underlining is not part of the reStructuredText specification.
***************
*** 427,431 ****
  StructuredText's markup for inline literals (text left as-is,
  verbatim, usually in a monospaced font; as in HTML <TT>) is single
! quotes ('literals'). The problem with single quotes is that they are
  too often used for other purposes:
  
--- 428,432 ----
  StructuredText's markup for inline literals (text left as-is,
  verbatim, usually in a monospaced font; as in HTML <TT>) is single
! quotes ('literals').  The problem with single quotes is that they are
  too often used for other purposes:
  
***************
*** 448,452 ****
  
  The examples below contain inline literals, quoted text, and
! apostrophes. Each example should evaluate to the following HTML::
  
      Some <TT>code</TT>, with a 'quote', "double", ain't it grand?
--- 449,453 ----
  
  The examples below contain inline literals, quoted text, and
! apostrophes.  Each example should evaluate to the following HTML::
  
      Some <TT>code</TT>, with a 'quote', "double", ain't it grand?
***************
*** 480,497 ****
          Does ``a[b] = 'c' + "d" + `2^3\``` work?
  
! Backquotes (#9 & #12) are the best choice. They are unobtrusive and
! relatviely rarely used (more rarely than ' or ", anyhow). Backquotes
  have the connotation of 'quotes', which other options (like carets,
  #10) don't.
  
  Analogously with ``*emph*`` & ``**strong**``, double-backquotes (#12)
! could be used for inline literals. If single-backquotes are used for
  'interpreted text' (context-sensitive domain-specific descriptive
  markup) such as function name hyperlinks in Python docstrings, then
  double-backquotes could be used for absolute-literals, wherein no
! processing whatsoever takes place. An advantage of double-backquotes
  would be that backslash-escaping would no longer be necessary for
  embedded single-backquotes; however, embedded double-backquotes (in an
! end-string context) would be illegal. See `Backquotes in
  Phrase-Links`__ in `Record of reStructuredText Syntax Alternatives`__.
  
--- 481,498 ----
          Does ``a[b] = 'c' + "d" + `2^3\``` work?
  
! Backquotes (#9 & #12) are the best choice.  They are unobtrusive and
! relatviely rarely used (more rarely than ' or ", anyhow).  Backquotes
  have the connotation of 'quotes', which other options (like carets,
  #10) don't.
  
  Analogously with ``*emph*`` & ``**strong**``, double-backquotes (#12)
! could be used for inline literals.  If single-backquotes are used for
  'interpreted text' (context-sensitive domain-specific descriptive
  markup) such as function name hyperlinks in Python docstrings, then
  double-backquotes could be used for absolute-literals, wherein no
! processing whatsoever takes place.  An advantage of double-backquotes
  would be that backslash-escaping would no longer be necessary for
  embedded single-backquotes; however, embedded double-backquotes (in an
! end-string context) would be illegal.  See `Backquotes in
  Phrase-Links`__ in `Record of reStructuredText Syntax Alternatives`__.
  
***************
*** 499,503 ****
  __ alternatives.html
  
! Alternative choices are carets (#10) and TeX-style quotes (#11). For
  examples of TeX-style quoting, see
  http://www.zope.org/Members/jim/StructuredTextWiki/CustomizingTheDocumentProcessor.
--- 500,504 ----
  __ alternatives.html
  
! Alternative choices are carets (#10) and TeX-style quotes (#11).  For
  examples of TeX-style quoting, see
  http://www.zope.org/Members/jim/StructuredTextWiki/CustomizingTheDocumentProcessor.
***************
*** 516,527 ****
  
  Outside of inline literals, the above uses of backquotes would require
! backslash-escaping. However, these are all prime examples of text that
! should be marked up with inline literals.
  
  If either backquotes or straight single-quotes are used as markup,
  TeX-quotes are too troublesome to support, so no special-casing of
! TeX-quotes should be done (at least at first). If TeX-quotes have to
  be used outside of literals, a single backslash-escaped would suffice:
! \``TeX quote''. Ugly, true, but very infrequently used.
  
  Using literal blocks is a fallback option which removes the need for
--- 517,528 ----
  
  Outside of inline literals, the above uses of backquotes would require
! backslash-escaping.  However, these are all prime examples of text
! that should be marked up with inline literals.
  
  If either backquotes or straight single-quotes are used as markup,
  TeX-quotes are too troublesome to support, so no special-casing of
! TeX-quotes should be done (at least at first).  If TeX-quotes have to
  be used outside of literals, a single backslash-escaped would suffice:
! \``TeX quote''.  Ugly, true, but very infrequently used.
  
  Using literal blocks is a fallback option which removes the need for
***************
*** 533,539 ****
  
  No mechanism for inline literals is perfect, just as no escaping
! mechanism is perfect. No matter what we use, complicated inline
  expressions involving the inline literal quote and/or the backslash
! will end up looking ugly. We can only choose the least often ugly
  option.
  
--- 534,540 ----
  
  No mechanism for inline literals is perfect, just as no escaping
! mechanism is perfect.  No matter what we use, complicated inline
  expressions involving the inline literal quote and/or the backslash
! will end up looking ugly.  We can only choose the least often ugly
  option.
  
***************
*** 547,557 ****
  There are three forms of hyperlink currently in StructuredText_:
  
! 1. (Absolute & relative URIs.) Text enclosed by double quotes followed
!    by a colon, a URI, and concluded by punctuation plus white space,
!    or just white space, is treated as a hyperlink::
  
         "Python":http://www.python.org/
  
! 2. (Absolute URIs only.) Text enclosed by double quotes followed by a
     comma, one or more spaces, an absolute URI and concluded by
     punctuation plus white space, or just white space, is treated as a
--- 548,558 ----
  There are three forms of hyperlink currently in StructuredText_:
  
! 1. (Absolute & relative URIs.)  Text enclosed by double quotes
!    followed by a colon, a URI, and concluded by punctuation plus white
!    space, or just white space, is treated as a hyperlink::
  
         "Python":http://www.python.org/
  
! 2. (Absolute URIs only.)  Text enclosed by double quotes followed by a
     comma, one or more spaces, an absolute URI and concluded by
     punctuation plus white space, or just white space, is treated as a
***************
*** 560,566 ****
         "mail me", mailto:me...@ma...
  
! 3. (Endnotes.) Text enclosed by brackets link to an endnote at the end
!    of the document: at the beginning of the line, two dots, a space,
!    and the same text in brackets, followed by the end note itself::
  
         Please refer to the fine manual [GVR2001].
--- 561,568 ----
         "mail me", mailto:me...@ma...
  
! 3. (Endnotes.)  Text enclosed by brackets link to an endnote at the
!    end of the document: at the beginning of the line, two dots, a
!    space, and the same text in brackets, followed by the end note
!    itself::
  
         Please refer to the fine manual [GVR2001].
***************
*** 570,577 ****
  
  The problem with forms 1 and 2 is that they are neither intuitive nor
! unobtrusive (they break design goals 5 & 2). They overload
  double-quotes, which are too often used in ordinary text (potentially
! breaking design goal 4). The brackets in form 3 are also too common in
! ordinary text (such as [nested] asides and Python lists like [12]).
  
  Alternatives:
--- 572,579 ----
  
  The problem with forms 1 and 2 is that they are neither intuitive nor
! unobtrusive (they break design goals 5 & 2).  They overload
  double-quotes, which are too often used in ordinary text (potentially
! breaking design goal 4).  The brackets in form 3 are also too common
! in ordinary text (such as [nested] asides and Python lists like [12]).
  
  Alternatives:
***************
*** 581,585 ****
  2. A. Interpret and mark up hyperlinks as any contiguous text
        containing '://' or ':...@' (absolute URI) or '@' (email
!       address) after an alphanumeric word. To de-emphasize the URI,
        simply enclose it in parentheses:
  
--- 583,587 ----
  2. A. Interpret and mark up hyperlinks as any contiguous text
        containing '://' or ':...@' (absolute URI) or '@' (email
!       address) after an alphanumeric word.  To de-emphasize the URI,
        simply enclose it in parentheses:
  
***************
*** 589,593 ****
        Hyperlinks in ordinary reStructuredText documents would be
        required to be standalone (i.e. the URI text inline in the
!       document text). Processed hyperlinks (where the URI text is
        hidden behind the link) are important enough to warrant syntax.
  
--- 591,595 ----
        Hyperlinks in ordinary reStructuredText documents would be
        required to be standalone (i.e. the URI text inline in the
!       document text).  Processed hyperlinks (where the URI text is
        hidden behind the link) are important enough to warrant syntax.
  
***************
*** 610,614 ****
  Since each source link must match up to a target, the odd variable
  ending in an underscore can be spared being marked up (although it
! should generate a "no such link target" warning). The only
  disadvantage is that phrase-links aren't possible without some
  obtrusive syntax.
--- 612,616 ----
  Since each source link must match up to a target, the odd variable
  ending in an underscore can be spared being marked up (although it
! should generate a "no such link target" warning).  The only
  disadvantage is that phrase-links aren't possible without some
  obtrusive syntax.
***************
*** 628,638 ****
         `like this`_
  
! Each gives us somewhat obtrusive markup, but that is unavoidable. The
  bracketed syntax (#2) is reminiscent of links on many web pages
! (intuitive), although it is somewhat obtrusive. Alternative #3 is much
! less obtrusive, and is consistent with interpreted text: the trailing
! underscore indicates the interpretation of the phrase, as a hyperlink.
! #3 also disambiguates hyperlinks from footnote references. Alternative
! #3 wins.
  
  The same trailing underscore markup can also be used for footnote and
--- 630,640 ----
         `like this`_
  
! Each gives us somewhat obtrusive markup, but that is unavoidable.  The
  bracketed syntax (#2) is reminiscent of links on many web pages
! (intuitive), although it is somewhat obtrusive.  Alternative #3 is
! much less obtrusive, and is consistent with interpreted text: the
! trailing underscore indicates the interpretation of the phrase, as a
! hyperlink.  #3 also disambiguates hyperlinks from footnote references.
! Alternative #3 wins.
  
  The same trailing underscore markup can also be used for footnote and
***************
*** 648,655 ****
  comments, which are removed from the (visible) processed output.
  reStructuredText uses this syntax for comments, footnotes, and link
! target, collectively termed "explicit markup". For link targets, in
  order to eliminate ambiguity with comments and footnotes,
  reStructuredText specifies that a colon always follow the link target
! word/phrase. The colon denotes 'maps to'. There is no reason to
  restrict target links to the end of the document; they could just as
  easily be interspersed.
--- 650,657 ----
  comments, which are removed from the (visible) processed output.
  reStructuredText uses this syntax for comments, footnotes, and link
! target, collectively termed "explicit markup".  For link targets, in
  order to eliminate ambiguity with comments and footnotes,
  reStructuredText specifies that a colon always follow the link target
! word/phrase.  The colon denotes 'maps to'.  There is no reason to
  restrict target links to the end of the document; they could just as
  easily be interspersed.
***************
*** 657,661 ****
  Internal hyperlinks (links from one point to another within a single
  document) can be expressed by a source link as before, and a target
! link with a colon but no URI. In effect, these targets 'map to' the
  element immediately following.
  
--- 659,663 ----
  Internal hyperlinks (links from one point to another within a single
  document) can be expressed by a source link as before, and a target
! link with a colon but no URI.  In effect, these targets 'map to' the
  element immediately following.
  
***************
*** 689,704 ****
  
  The presence or absence of a colon after the target link
! differentiates an indirect hyperlink from a footnote, respectively. A
! footnote requires brackets. Backquotes around a target link word or
  phrase are required if the phrase contains a colon, optional
  otherwise.
  
  Below are examples using no markup, the two StructuredText hypertext
! styles, and the reStructuredText hypertext style. Each example
  contains an indirect link, a direct link, a footnote/endnote, and
! bracketed text. In HTML, each example should evaluate to::
  
      <P>A <A HREF="http://spam.org">URI</A>, see <A HREF="#eggs2000">
!     [eggs2000]</A> (in Bacon [Publisher]). Also see
      <A HREF="http://eggs.org">http://eggs.org</A>.</P>
  
--- 691,706 ----
  
  The presence or absence of a colon after the target link
! differentiates an indirect hyperlink from a footnote, respectively.  A
! footnote requires brackets.  Backquotes around a target link word or
  phrase are required if the phrase contains a colon, optional
  otherwise.
  
  Below are examples using no markup, the two StructuredText hypertext
! styles, and the reStructuredText hypertext style.  Each example
  contains an indirect link, a direct link, a footnote/endnote, and
! bracketed text.  In HTML, each example should evaluate to::
  
      <P>A <A HREF="http://spam.org">URI</A>, see <A HREF="#eggs2000">
!     [eggs2000]</A> (in Bacon [Publisher]).  Also see
      <A HREF="http://eggs.org">http://eggs.org</A>.</P>
  
***************
*** 729,733 ****
  
         A "URI", http://spam.org, see [eggs2000] (in Bacon
!        [Publisher]). Also see "http://eggs.org", http://eggs.org.
  
         .. [eggs2000] "Spam, Spam, Spam, Eggs, Bacon, and Spam"
--- 731,735 ----
  
         A "URI", http://spam.org, see [eggs2000] (in Bacon
!        [Publisher]).  Also see "http://eggs.org", http://eggs.org.
  
         .. [eggs2000] "Spam, Spam, Spam, Eggs, Bacon, and Spam"
***************
*** 744,748 ****
  StructuredText (syntax 2 & 3).
  
! reStructuredText's syntax (#4) is definitely the most readable. The
  text is separated from the link URI and the footnote, resulting in
  cleanly readable text.
--- 746,750 ----
  StructuredText (syntax 2 & 3).
  
! reStructuredText's syntax (#4) is definitely the most readable.  The
  text is separated from the link URI and the footnote, resulting in
  cleanly readable text.

[Structuredtext-checkins] CVS: restructuredtext/spec introduction.txt,1.9,1.10

From: David G. <go...@us...> - 2002-04-18 02:42:51

Update of /cvsroot/structuredtext/restructuredtext/spec
In directory usw-pr-cvs1:/tmp/cvs-serv12622/restructuredtext/spec

Modified Files:
	introduction.txt 
Log Message:
Fixed whitespace & updated

Index: introduction.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/spec/introduction.txt,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** introduction.txt	28 Mar 2002 04:27:31 -0000	1.9
--- introduction.txt	18 Apr 2002 02:42:48 -0000	1.10
***************
*** 48,52 ****
    expression of structure within plaintext, and
  
! - the conversion of such documents into useful structured data formats.
  
  The secondary goal of reStructuredText is to be accepted by the Python
--- 48,53 ----
    expression of structure within plaintext, and
  
! - the conversion of such documents into useful structured data
!   formats.
  
  The secondary goal of reStructuredText is to be accepted by the Python
***************
*** 245,251 ****
  completed in early March.
  
  Version 0.4 of the reStructuredText_ and `Docstring Processing
! System`_ projects were released on @@@.  The two projects were
! immediately merged and renamed "Docutils_", and a 0.1 release soon
  followed.
  
--- 246,257 ----
  completed in early March.
  
+ `PEP 287`_, "reStructuredText Standard Docstring Format", was created
+ to formally propose reStructuredText as a standard format for Python
+ docstrings, PEPs, and other files.  It was first posted to
+ comp.lang.python_ and the Python-dev_ mailing list on 2002-04-02.
+ 
  Version 0.4 of the reStructuredText_ and `Docstring Processing
! System`_ projects were released on 2002-04-??.  The two projects were
! immediately merged, renamed to "Docutils_", and a 0.1 release soon
  followed.
  
***************
*** 267,270 ****
--- 273,280 ----
     - `PEP 257: Docstring Conventions`__
  
+    Current working versions of the PEPs can be found in
+    http://docutils.sourceforge.net/spec/, and official versions can be
+    found in the `master PEP repository`_.
+ 
     __ http://mail.python.org/pipermail/doc-sig/2001-June/001855.html
     __ http://mail.python.org/pipermail/doc-sig/2001-June/001856.html
***************
*** 279,283 ****
--- 289,295 ----
  .. _HISTORY.txt:
      http://structuredtext.sourceforge.net/HISTORY.txt
+ .. _PEP 287: http://docutils.sourceforge.net/spec/pep-0287.txt
  .. _Docutils: http://docutils.sourceforge.net/
+ .. _master PEP repository: http://www.python.org/peps/

[Structuredtext-checkins] CVS: restructuredtext/test/test_states test_option_lists.py,1.9,1.10

From: David G. <go...@us...> - 2002-04-18 02:40:53

Update of /cvsroot/structuredtext/restructuredtext/test/test_states
In directory usw-pr-cvs1:/tmp/cvs-serv12029/restructuredtext/test/test_states

Modified Files:
	test_option_lists.py 
Log Message:
updated

Index: test_option_lists.py
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/test/test_states/test_option_lists.py,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -d -r1.9 -r1.10
*** test_option_lists.py	1 Mar 2002 03:00:21 -0000	1.9
--- test_option_lists.py	18 Apr 2002 02:40:50 -0000	1.10
***************
*** 494,508 ****
  """\
  <document>
-     <option_list>
-         <option_list_item>
-             <option_group>
-                 <option>
-                     <option_string>
-                         --option
-             <description>
-     <system_message level="2" type="WARNING">
-         <paragraph>
-             Unindent without blank line at line 2.
      <paragraph>
          empty item above, no blank line
  """],
--- 494,499 ----
  """\
  <document>
      <paragraph>
+         --option
          empty item above, no blank line
  """],
***************
*** 639,642 ****
--- 630,643 ----
  
  -                 this should be a bullet list item
+ 
+ These next ones should be simple paragraphs:
+ 
+ -1
+ 
+ --option
+ 
+ --1
+ 
+ -1 and this one too.
  """,
  """\
***************
*** 666,669 ****
--- 667,680 ----
              <paragraph>
                  this should be a bullet list item
+     <paragraph>
+         These next ones should be simple paragraphs:
+     <paragraph>
+         -1
+     <paragraph>
+         --option
+     <paragraph>
+         --1
+     <paragraph>
+         -1 and this one too.
  """],
  ]

[Structuredtext-checkins] CVS: restructuredtext HISTORY.txt,1.47,1.48

From: David G. <go...@us...> - 2002-04-14 19:40:25

Update of /cvsroot/structuredtext/restructuredtext
In directory usw-pr-cvs1:/tmp/cvs-serv24565/restructuredtext

Modified Files:
	HISTORY.txt 
Log Message:
updated

Index: HISTORY.txt
===================================================================
RCS file: /cvsroot/structuredtext/restructuredtext/HISTORY.txt,v
retrieving revision 1.47
retrieving revision 1.48
diff -C2 -d -r1.47 -r1.48
*** HISTORY.txt	16 Mar 2002 05:45:11 -0000	1.47
--- HISTORY.txt	14 Apr 2002 19:40:19 -0000	1.48
***************
*** 45,49 ****
    - Added 'restructuredtext.languages' subpackage.
  
! * docs: Subdirectory added. Contains quickref.html by Tony Ibbs.
  
  * restructuredtext/__init__.py:
--- 45,50 ----
    - Added 'restructuredtext.languages' subpackage.
  
! * docs: Subdirectory added. Contains quickref.html by Tony Ibbs and
!   quickstart.txt by Richard Jones.
  
  * restructuredtext/__init__.py:

[Structuredtext-checkins] CVS: web index.html.template,1.4,1.5

From: David G. <go...@us...> - 2002-04-13 16:57:42

Update of /cvsroot/structuredtext/web
In directory usw-pr-cvs1:/tmp/cvs-serv12249/web

Modified Files:
	index.html.template 
Log Message:
updated

Index: index.html.template
===================================================================
RCS file: /cvsroot/structuredtext/web/index.html.template,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** index.html.template	7 Sep 2001 02:44:39 -0000	1.4
--- index.html.template	13 Apr 2002 16:57:37 -0000	1.5
***************
*** 22,27 ****
  Processing System</A>. reStructuredText is a revision and reinterpretation of
  the <A HREF="http://dev.zope.org/Members/jim/StructuredTextWiki/FrontPage/"
! >StructuredText</A> and <A HREF="http://www.bsdi.com/setext/" >Setext</A>
! lightweight markup systems.</P>
  
  <P>The primary goal of the reStructuredText project is to define and implement
--- 22,27 ----
  Processing System</A>. reStructuredText is a revision and reinterpretation of
  the <A HREF="http://dev.zope.org/Members/jim/StructuredTextWiki/FrontPage/"
! >StructuredText</A> and <A HREF="http://docutils.sourceforge.net/mirror/setext.html"
! >Setext</A> lightweight markup systems.</P>
  
  <P>The primary goal of the reStructuredText project is to define and implement
***************
*** 40,66 ****
  &ldquo;<TT>dps.parsers.restructuredtext</TT>&rdquo;, a component of the <A
  HREF="http://docstring.sourceforge.net/">Python Docstring Processing System
! (DPS)</A>. The reStructuredText parser is almost complete. Only a few details
! remain to be implemented.</P>
! 
! <P>The <A
! HREF="http://prdownloads.sourceforge.net/structuredtext/`latest_rst_release`"
! >latest project release package (`latest_rst_release`)</A> and past project
! releases can be downloaded from the <A
! HREF="http://sourceforge.net/project/showfiles.php?group_id=7050">project
! files page</A>. Please also download the <A
! HREF="http://prdownloads.sourceforge.net/docstring/`latest_dps_release`"
! >latest DPS package (`latest_dps_release`)</A> which is required by the
! reStructuredText parser. <A
! HREF="http://sourceforge.net/cvs/?group_id=7050">Anonymous CVS access is
! available.</A> You can also <A
! HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/structuredtext/restructuredtext/"
! >browse the latest reStructuredText source files (CVS) individually</A>, and
! read the latest <A HREF="README.txt">README.txt</A> and <A
! HREF="HISTORY.txt">HISTORY.txt</A>.</P>
  
  <H3><A NAME="snapshots">Daily Snapshots</A></H3>
  
  <P>Daily snapshots of the project files are also available. They are
! generated automatically from CVS at 24:00 in North America's Eastern
  time zone (UTC-0400 from April to October, UTC-0500 from October to
  April). The snapshots should be used with caution, as they may contain
--- 40,49 ----
  &ldquo;<TT>dps.parsers.restructuredtext</TT>&rdquo;, a component of the <A
  HREF="http://docstring.sourceforge.net/">Python Docstring Processing System
! (DPS)</A>. The reStructuredText parser is functionally complete.</P>
  
  <H3><A NAME="snapshots">Daily Snapshots</A></H3>
  
  <P>Daily snapshots of the project files are also available. They are
! generated automatically from CVS around midnight in North America's Eastern
  time zone (UTC-0400 from April to October, UTC-0500 from October to
  April). The snapshots should be used with caution, as they may contain
***************
*** 86,89 ****
--- 69,93 ----
  </UL>
  
+ <H3><A NAME="releases">Project Releases</A></H3>
+ 
+ <P>Please note that the <A HREF="#snapshots">snapshots</A> above
+ contain the latest versions of project files.</P>
+ 
+ <P>The <A
+ HREF="http://prdownloads.sourceforge.net/structuredtext/`latest_rst_release`"
+ >latest project release package (`latest_rst_release`)</A> and past project
+ releases can be downloaded from the <A
+ HREF="http://sourceforge.net/project/showfiles.php?group_id=7050">project
+ files page</A>. Please also download the <A
+ HREF="http://prdownloads.sourceforge.net/docstring/`latest_dps_release`"
+ >latest DPS package (`latest_dps_release`)</A> which is required by the
+ reStructuredText parser. <A
+ HREF="http://sourceforge.net/cvs/?group_id=7050">Anonymous CVS access is
+ available.</A> You can also <A
+ HREF="http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/structuredtext/restructuredtext/"
+ >browse the latest reStructuredText source files (CVS) individually</A>, and
+ read the latest <A HREF="README.txt">README.txt</A> and <A
+ HREF="HISTORY.txt">HISTORY.txt</A>.</P>
+ 
  <H2>User Documentation</H2>
  
***************
*** 97,103 ****
  
  <UL>
   <LI><P><A
       HREF="docs/quickref.html"
!      >Quick reStructuredText</A>
       </P></LI>
  </UL>
--- 101,112 ----
  
  <UL>
+ 
+  <LI><P><A HREF="docs/quickstart.html">A ReStructuredText Primer</A> (HTML file),
+         and <A HREF="docs/quickstart.txt">A ReStructuredText Primer</A> (text source).
+      </P></LI>
+ 
   <LI><P><A
       HREF="docs/quickref.html"
!      >Quick reStructuredText</A> (user reference)
       </P></LI>
  </UL>
***************
*** 126,130 ****
   <LI><P><A
       HREF="spec/alternatives.txt"
!      >Record of reStructuredText Syntax Alternatives</A>
       </P></LI>
  
--- 135,139 ----
   <LI><P><A
       HREF="spec/alternatives.txt"
!      >A Record of reStructuredText Syntax Alternatives</A>
       </P></LI>

Flat | Threaded

1 2 3 .. 26 > >> (Page 1 of 26)

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (83)	Sep (171)	Oct (49)	Nov (58)	Dec
2002	Jan (34)	Feb (76)	Mar (111)	Apr (47)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec