On Mon, 12 Jan 2009, C�dric Villemain wrote:
> we, at dalibo, used to write our docs with ReST and most of the time we
> don't need to escape special char
I'm interested in this patch for a similar reason, ReST has been working
well for internal documentation at my office. I know I'll run into tables
that require massive escaping on the datasets I have here though. You
might have gotten lucky and had data with little punctuation, I don't
think the user base at large will.
Here's the simplest real-world example I found. This is from an app that
collects PC information. I fudged the second row to pick something that's
still realistic from this problem domain and looks more like markup:
+--------------+-------------------+
| ip | file |
+==============+===================+
| 192.168.0.1 | C:\WINDOWS\SYSTEM |
+--------------+-------------------+
| 192.168.0.1 | *.* |
+--------------+-------------------+
That renders like this:
ip file
192.168.0.1 C:WINDOWSSYSTEM
192.168.0.1 .
Which is no good. Escaping it must transform the text first, recompute
the widths based on that, and then display the table. That gives the
following:
+--------------+---------------------+
| ip | file |
+==============+=====================+
| 192.168.0.1 | C:\\WINDOWS\\SYSTEM |
+--------------+---------------------+
| 192.168.0.2 | \*.\* |
+--------------+---------------------+
As the shortest right thing to do.
I think the problem with the single markup character injection test D'Arcy
ran is that many of these only matter if two appear on a line; to get
italics you need two * characters for example, so showing a single *
doesn't get mangled doesn't prove anything. What I would normally want
next in this sort of situation is some more table input designed to render
badly for testing. I'll see what I can put together there, I am rather
good at breaking code.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
