Index: jrst2/src/test/org/codelutin/jrst/Compare.java diff -u jrst2/src/test/org/codelutin/jrst/Compare.java:1.2 jrst2/src/test/org/codelutin/jrst/Compare.java:1.3 --- jrst2/src/test/org/codelutin/jrst/Compare.java:1.2 Wed May 9 08:36:16 2007 +++ jrst2/src/test/org/codelutin/jrst/Compare.java Tue May 22 09:24:00 2007 @@ -1,5 +1,8 @@ package org.codelutin.jrst; +import java.awt.BorderLayout; +import java.awt.Color; +import java.awt.Font; import java.io.BufferedReader; import java.io.File; import java.io.IOException; @@ -7,19 +10,35 @@ import java.io.Reader; import java.io.StringWriter; import java.net.URL; +import java.util.LinkedList; +import java.util.List; +import java.util.regex.Matcher; +import java.util.regex.Pattern; + import javax.swing.JFrame; +import javax.swing.JPanel; import javax.swing.JScrollPane; import javax.swing.JSplitPane; import javax.swing.JTextArea; +import javax.swing.JTextPane; +import javax.swing.text.JTextComponent; + import org.codelutin.jrst.JRSTReader; +import org.custommonkey.xmlunit.DetailedDiff; +import org.custommonkey.xmlunit.XMLUnit; import org.dom4j.Document; import org.dom4j.io.OutputFormat; import org.dom4j.io.SAXReader; import org.dom4j.io.XMLWriter; + import sdoc.*; public class Compare { - private static final String PATH="/home/letellier/PROJET/jrst2/"; // a redefinir manuelement + static boolean[] bColorRst ; + static boolean[] bColorPython; + private static final String PATH="/home/letellier/PROJET/jrst2/"; // a + // redefinir + // manuelement static public void main(String [] args) throws Exception { File source = null; if (args.length>0){ @@ -45,7 +64,8 @@ String line = ""; try { while((line = reader.readLine()) != null) { - System.err.println(line); // Pour rediriger la sortie des érreurs + System.err.println(line); // Pour rediriger la + // sortie des érreurs } } finally { reader.close(); @@ -62,31 +82,103 @@ File xml = new File("src/test/org/codelutin/jrst/comparePython.xml"); SAXReader sr= new SAXReader(); Document docPython = sr.read(xml); - compare(docRst, docPython); + String diff = test(docRst, docPython); + + String sDocRst = indent(docRst); // On indente + String sDocPython = indent(docPython); + compare(sDocRst, sDocPython, diff); } - private static void compare(Document docRst, Document docPython) throws IOException { - JTextArea jrst = new JTextArea(); + private static String test(Document docRst, Document docPython) throws Exception { + String[] sDocRst = indent(docRst).split("\n"); + bColorRst = new boolean[sDocRst.length]; + for (int i=0;i names = new LinkedList(); + LinkedList rgs = new LinkedList(); + while (matcher2.find()){ + names.add(matcher2.group().substring(1,matcher2.group().indexOf("["))); + rgs.add(Integer.valueOf(matcher2.group().substring(matcher2.group().indexOf("[")+1,matcher2.group().indexOf("]")))); + + } + int cntName=0; + int nbLine=0; + for (String name : names){ + int trouve=0; + for (int i=nbLine;i -<image alt="reStructuredText" uri="rst.png"/>Markup Syntax and Parser Component of Docutils2007-05-04Contents1   User Documentation2   Reference Documentation3   Developer Documentation3.1   How-To's4   Try it OnlinereStructuredText is an easy-to-read, what-you-see-is-what-you-get -plaintext markup syntax and parser system. It is useful for in-line +An Introduction to reStructuredTextMarkup Syntax and Parser Component of DocutilsDavid Goodgergoodger@python.org1.42007-05-11This document has been placed in the public domain.reStructuredText is an easy-to-read, what-you-see-is-what-you-get +plaintext markup syntax and parser system. It is useful for inline 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. The reStructuredText parser is a component of -Docutils. reStructuredText is a revision and reinterpretation of the -StructuredText and Setext lightweight markup systems.The primary goal of reStructuredText 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.See statemachine.py for an example of a Python module fully -documented using reStructuredText.
<generated class="sectnum">1   </generated>User DocumentationA ReStructuredText Primer (HTML file, or text source).Quick reStructuredText (user reference)reStructuredText Cheat Sheet (text only; 1 page for syntax, 1 -page directive & role reference)Users who have questions or need assistance with Docutils or -reStructuredText should post a message to the Docutils-users mailing -list.
<generated class="sectnum">2   </generated>Reference DocumentationAn Introduction to reStructuredText (includes the Goals and -History of reStructuredText)reStructuredText Markup SpecificationreStructuredText DirectivesreStructuredText Interpreted Text Roles
<generated class="sectnum">3   </generated>Developer DocumentationA Record of reStructuredText Syntax AlternativesProblems With StructuredText
<generated class="sectnum">3.1   </generated>How-To'sCreating reStructuredText DirectivesCreating reStructuredText Interpreted Text Roles
<generated class="sectnum">4   </generated>Try it OnlineIf you want to try reStructuredText out without downloading Docutils, -you can use the reStructuredText online renderer. Thanks to Jiri -Barton for setting it up!reStructuredTextLocal Variables: +reStructuredText is a proposed revision and reinterpretation of the +StructuredText and Setext lightweight markup systems.reStructuredText is designed for extensibility for specific +application domains. Its parser is a component of Docutils.This document defines the goals of reStructuredText and provides a +history of the project. It is written using the reStructuredText +markup, and therefore serves as an example of its use. For a gentle +introduction to using reStructuredText, please read A +ReStructuredText Primer. The Quick reStructuredText user +reference is also useful. The reStructuredText Markup +Specification is the definitive reference. There is also an +analysis of the Problems With StructuredText.ReStructuredText's web page is +http://docutils.sourceforge.net/rst.html.ContentsGoalsHistory
GoalsThe primary goal of reStructuredText is to define 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 reStructuredText markup is twofold:the establishment of a set of standard conventions allowing the +expression of structure within plaintext, andthe conversion of such documents into useful structured data +formats.The secondary goal of reStructuredText is to be accepted by the Python +community (by way of being blessed by PythonLabs and the BDFL 1) as +a standard for Python inline documentation (possibly one of several +standards, to account for taste).Python's creator and "Benevolent Dictator For Life", +Guido van Rossum.To clarify the primary goal, here are specific design goals, in order, +beginning with the most important:Readable. The marked-up text must be easy to read without any +prior knowledge of the markup language. It should be as easily +read in raw form as in processed form.Unobtrusive. The markup that is used should be as simple and +unobtrusive as possible. The simplicity of markup constructs +should be roughly proportional to their frequency of use. The most +common constructs, with natural and obvious markup, should be the +simplest and most unobtrusive. Less common constructs, for which +there is no natural or obvious markup, should be distinctive.Unambiguous. The rules for markup must not be open for +interpretation. For any given input, there should be one and only +one possible output (including error output).Unsurprising. Markup constructs should not cause unexpected output +upon processing. As a fallback, there must be a way to prevent +unwanted markup processing when a markup construct is used in a +non-markup context (for example, when documenting the markup syntax +itself).Intuitive. Markup should be as obvious and easily remembered as +possible, for the author as well as for the reader. Constructs +should take their cues from such naturally occurring sources as +plaintext email messages, newsgroup postings, and text +documentation such as README.txt files.Easy. It should be easy to mark up text using any ordinary text +editor.Scalable. The markup should be applicable regardless of the length +of the text.Powerful. The markup should provide enough constructs to produce a +reasonably rich structured document.Language-neutral. The markup should apply to multiple natural (as +well as artificial) languages, not only English.Extensible. The markup should provide a simple syntax and +interface for adding more complex general markup, and custom +markup.Output-format-neutral. The markup will be appropriate for +processing to multiple output formats, and will not be biased +toward any particular format.The design goals above were used as criteria for accepting or +rejecting syntax, or selecting between alternatives.It is emphatically not the goal of reStructuredText to define +docstring semantics, such as docstring contents or docstring length. +These issues are orthogonal to the markup syntax and beyond the scope +of this specification.Also, it is not the goal of reStructuredText to maintain compatibility +with StructuredText or Setext. reStructuredText shamelessly steals +their great ideas and ignores the not-so-great.Author's note:Due to the nature of the problem we're trying to solve (or, +perhaps, due to the nature of the proposed solution), the above +goals unavoidably conflict. I have tried to extract and distill +the wisdom accumulated over the years in the Python Doc-SIG +mailing list and elsewhere, to come up with a coherent and +consistent set of syntax rules, and the above goals by which to +measure them.There will inevitably be people who disagree with my particular +choices. Some desire finer control over their markup, others +prefer less. Some are concerned with very short docstrings, +others with full-length documents. This specification is an +effort to provide a reasonably rich set of markup constructs in a +reasonably simple form, that should satisfy a reasonably large +group of reasonable people.David Goodger (goodger@python.org), 2001-04-20
HistoryreStructuredText, the specification, is based on StructuredText and +Setext. StructuredText was developed by Jim Fulton of Zope +Corporation (formerly Digital Creations) and first released in 1996. +It is now released as a part of the open-source "Z Object Publishing +Environment" (ZOPE). Ian Feldman's and Tony Sanders' earlier Setext +specification was either an influence on StructuredText or, by their +similarities, at least evidence of the correctness of this approach.I discovered StructuredText in late 1999 while searching for a way to +document the Python modules in one of my projects. Version 1.1 of +StructuredText was included in Daniel Larsson's pythondoc. Although +I was not able to get pythondoc to work for me, I found StructuredText +to be almost ideal for my needs. I joined the Python Doc-SIG +(Documentation Special Interest Group) mailing list and found an +ongoing discussion of the shortcomings of the StructuredText +"standard". This discussion has been going on since the inception of +the mailing list in 1996, and possibly predates it.I decided to modify the original module with my own extensions and +some suggested by the Doc-SIG members. I soon realized that the +module was not written with extension in mind, so I embarked upon a +general reworking, including adapting it to the "re" regular +expression module (the original inspiration for the name of this +project). Soon after I completed the modifications, I discovered that +StructuredText.py was up to version 1.23 in the ZOPE distribution. +Implementing the new syntax extensions from version 1.23 proved to be +an exercise in frustration, as the complexity of the module had become +overwhelming.In 2000, development on StructuredTextNG ("Next Generation") began at +Zope Corporation (then Digital Creations). It seems to have many +improvements, but still suffers from many of the problems of classic +StructuredText.I decided that a complete rewrite was in order, and even started a +reStructuredText SourceForge project (now inactive). My +motivations (the "itches" I aim to "scratch") are as follows:I need a standard format for inline documentation of the programs I +write. This inline documentation has to be convertible to other +useful formats, such as HTML. I believe many others have the same +need.I believe in the Setext/StructuredText idea and want to help +formalize the standard. However, I feel the current specifications +and implementations have flaws that desperately need fixing.reStructuredText could form part of the foundation for a +documentation extraction and processing system, greatly benefitting +Python. But it is only a part, not the whole. reStructuredText is +a markup language specification and a reference parser +implementation, but it does not aspire to be the entire system. I +don't want reStructuredText or a hypothetical Python documentation +processor to die stillborn because of over-ambition.Most of all, I want to help ease the documentation chore, the bane +of many a programmer.Unfortunately I was sidetracked and stopped working on this project. +In November 2000 I made the time to enumerate the problems of +StructuredText and possible solutions, and complete the first draft of +a specification. This first draft was posted to the Doc-SIG in three +parts:A Plan for Structured TextProblems With StructuredTextreStructuredText: Revised Structured Text SpecificationIn March 2001 a flurry of activity on the Doc-SIG spurred me to +further revise and refine my specification, the result of which you +are now reading. An offshoot of the reStructuredText project has been +the realization that a single markup scheme, no matter how well +thought out, may not be enough. In order to tame the endless debates +on Doc-SIG, a flexible Docstring Processing System framework needed +to be constructed. This framework has become the more important of +the two projects; reStructuredText has found its place as one +possible choice for a single component of the larger framework.The project web site and the first project release were rolled out in +June 2001, including posting the second draft of the spec 2 +and the first draft of PEPs 256, 257, and 258 3 to the +Doc-SIG. These documents and the project implementation proceeded to +evolve at a rapid pace. Implementation history details can be found +in the project history file.In November 2001, the reStructuredText parser was nearing completion. +Development of the parser continued with the addition of small +convenience features, improvements to the syntax, the filling in of +gaps, and bug fixes. After a long holiday break, in early 2002 most +development moved over to the other Docutils components, the +"Readers", "Writers", and "Transforms". A "standalone" reader +(processes standalone text file documents) was completed in February, +and a basic HTML writer (producing HTML 4.01, using CSS-1) was +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 in April 2002. The two projects were +immediately merged, renamed to "Docutils", and a 0.1 release soon +followed.The second draft of the spec:An Introduction to reStructuredTextProblems With StructuredTextreStructuredText Markup SpecificationPython Extensions to the reStructuredText Markup SpecificationFirst drafts of the PEPs:PEP 256: Docstring Processing System FrameworkPEP 258: DPS Generic Implementation DetailsPEP 257: Docstring ConventionsCurrent working versions of the PEPs can be found in +http://docutils.sourceforge.net/docs/peps/, and official versions +can be found in the master PEP repository.Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t Index: jrst2/src/test/org/codelutin/jrst/xmlunit-1.1beta1.jar Index: jrst2/src/test/org/codelutin/jrst/XMLCaseTest.java diff -u /dev/null jrst2/src/test/org/codelutin/jrst/XMLCaseTest.java:1.1 --- /dev/null Tue May 22 09:24:06 2007 +++ jrst2/src/test/org/codelutin/jrst/XMLCaseTest.java Tue May 22 09:24:00 2007 @@ -0,0 +1,22 @@ +package org.codelutin.jrst; + +import org.custommonkey.xmlunit.DetailedDiff; +import org.custommonkey.xmlunit.XMLTestCase; + + + +public class XMLCaseTest extends XMLTestCase { + public XMLCaseTest(String name) { + super(name); + } + + + + public DetailedDiff testAllDifferences(String myControlXML,String myTestXML) throws Exception { + DetailedDiff myDiff = new DetailedDiff(compareXML(myControlXML, myTestXML)); + return myDiff; + + } + + +} Index: jrst2/src/test/org/codelutin/jrst/GutterColor.java diff -u /dev/null jrst2/src/test/org/codelutin/jrst/GutterColor.java:1.1 --- /dev/null Tue May 22 09:24:06 2007 +++ jrst2/src/test/org/codelutin/jrst/GutterColor.java Tue May 22 09:24:00 2007 @@ -0,0 +1,160 @@ +package org.codelutin.jrst; +/* +* +* Created on 1 aout 2005, 17:45 +* +* Copyright (C) 2005 Yves Zoundi +* MOdified by Jason Davis +* +* This library is free software; you can redistribute it and/or modify +* it under the terms of the GNU Lesser General Public License as published +* by the Free Software Foundation; either version 2.1 of the License, or +* (at your option) any later version. +* +* This library is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU Lesser General Public License for more details. +* +* You should have received a copy of the GNU Lesser General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +import java.awt.Color; +import java.awt.Dimension; +import java.awt.FontMetrics; +import java.awt.GradientPaint; +import java.awt.Graphics2D; +import java.awt.Rectangle; +import java.awt.RenderingHints; +import java.awt.event.AdjustmentEvent; +import java.awt.event.AdjustmentListener; +import java.beans.PropertyChangeEvent; +import java.beans.PropertyChangeListener; + +import javax.swing.JLabel; +import javax.swing.JScrollPane; +import javax.swing.text.JTextComponent; + + +/** +* A class which adds line numbering to a editor +* +* @author Yves Zoundi +*/ +public final class GutterColor extends JLabel +{ + + private JTextComponent edit; + private int rhWidth = 40; + boolean[] bColors; + /** + * + * @param edit + * the editor which has to display line numbers + */ + public GutterColor(JTextComponent edit, JScrollPane pane, boolean[] bColors) + { + this.edit = edit; + this.bColors = bColors; + //listen for font change + edit.addPropertyChangeListener(new PropertyChangeListener() + { + public void propertyChange(PropertyChangeEvent evt) + { + if(evt.getPropertyName().equals("font")) + { + revalidate(); + repaint(); + } + } + }); + + setBackground(Color.GRAY); + setForeground(Color.GRAY.darker()); + + pane.getVerticalScrollBar().addAdjustmentListener(new AdjustmentListener() + { + public void adjustmentValueChanged(AdjustmentEvent e) + { + revalidate(); + repaint(); + } + }); + } + + /** + * + * @return The preferred size of the line numbering column + */ + public Dimension getPreferredSize() + { + FontMetrics fm = edit.getFontMetrics(edit.getFont()); + int h = fm.getHeight(); + int w = fm.stringWidth(String.valueOf(edit.getHeight() / h)) + 6; + + rhWidth = w; + int hi = (int) edit.getPreferredSize().getHeight(); + return new Dimension(w, hi); + } + + /** + * + * @param g + * A graphic component + */ + public void paintComponent(java.awt.Graphics g) + { + super.paintComponent(g); + + Graphics2D g2d = (Graphics2D) g; + g2d.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_OFF); + + g2d.setFont(edit.getFont()); + FontMetrics fm = g2d.getFontMetrics(); + + Rectangle rec = edit.getVisibleRect(); + + int h = fm.getHeight(); + int row = rec.y / h; + int i = h - fm.getDescent(); + i += h * row; + int max = row + (rec.height / h) + 2; + + boolean doWhite = false; + while (row < max) + { + String s = Integer.toString(row + 1) + " "; + boolean white = false; + if (bColors.length>row+1){ + if (bColors[row+1]){ + g2d.setColor(Color.RED); + g2d.fill3DRect(1, i+3, 20, 15, false); + white=true; + + } + else + white=false; + } + else + white=false; + if (doWhite){ + g2d.setColor(Color.WHITE); + g2d.drawString(s, (rhWidth + 9) - fm.stringWidth(s), i); + } + else{ + g2d.setColor(Color.GRAY.darker()); + g2d.drawString(s, (rhWidth + 9) - fm.stringWidth(s), i); + } + doWhite=white; + + i += h; + row++; + } + + g2d.setColor(Color.GRAY.darker()); + g2d.drawLine(getWidth() - 3, rec.y, getWidth() - 3, rec.height + rec.y); + } +} +