Re: Proposal: new border setting in psql
От | Greg Smith |
---|---|
Тема | Re: Proposal: new border setting in psql |
Дата | |
Msg-id | Pine.GSO.4.64.0901081829530.2578@westnet.com обсуждение исходный текст |
Ответ на | Re: Proposal: new border setting in psql ("D'Arcy J.M. Cain" <darcy@druid.net>) |
Ответы |
Re: Proposal: new border setting in psql
|
Список | pgsql-hackers |
On Thu, 8 Jan 2009, D'Arcy J.M. Cain wrote: > On Thu, 8 Jan 2009 13:51:44 -0500 (EST) > Greg Smith <gsmith@gregsmith.com> wrote: >> >> A. Einstein was a really smart dude. > Which character in the above example would you escape. "." is on the long list of characters to be escaped I sent out earlier. The parser looks for all sorts of enumeration syntaxes--A., I), (IV)--but they all require some punctuation which makes those characters the ones to focus on. > I would suggest that if we want actual ReST-safe output we should create > a "border = 4" setting. The code changes would be minimal. All we need > to do is check for a value of 4 in addition to checking whether escaping > is necessary. This seems like a reasonable spec to me. If you just want that general format, you can get that and may very well end up with something that's useful ReST anyway with the border=3 mode your existing patch implements. As you demonstrated, there are several situations where a character you think might do something special turns out to be ignored, with "\" being the most likely to cause trouble. If you really want something that will be valid ReST, use border=4, which adds escaping for everything inside the table that's on that long list of potential markup characters. That's going to make the table look quite ugly if you have many characters on the escape list, but I don't see any way to get around that without a heavy dependency on behavior that's only documented in the docutils implementation itself. The "spec" itself is really more of a user guide, and it sure isn't good enough to let you know every case where special characters may be interpreted as markup. As demonstrated with the Einstein example, you sometimes need a while line of lookahead to figure that out anyway, which makes a smarter escaping solution pretty hard to implement. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: