Re: Proposal: new border setting in psql

On Mon, 12 Jan 2009, Cdric 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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD