From: Bastien <bzg@altern.org>
To: Nathan Trapuzzano <nbtrap@nbtrap.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Bug: Table export to [tc]sv doesn't convert \vert [7.8.11]
Date: Mon, 31 Dec 2012 10:30:49 +0100 [thread overview]
Message-ID: <87obhao9fa.fsf@bzg.ath.cx> (raw)
In-Reply-To: <20121230230104.3314d945@nbtrap.com> (Nathan Trapuzzano's message of "Sun, 30 Dec 2012 23:01:04 -0500")
Hi Nathan,
Nathan Trapuzzano <nbtrap@nbtrap.com> writes:
> Of course the particular implementation will have to be seen before it
> can be accepted, but I'd like to get the spec accepted (provisionally)
> before setting to work on it.
As a start, you can look at the way org-e-*.el backend export tables,
(use `org-e-ascii-table-cell' as an entry point). What we need is a
callback function to convert entities in cells, in org-export.el.
Since we already have org-entities, I would use it together with
`org-entity-get-representation' to convert entities from the \vert{}
representation to the "|" character (in the ASCII backend.)
> Here's what I propose:
>
> 1. Do away with \vert{} entirely, leaving just \vert as an escape
> sequence standing for |, no matter where it appears. \vert{}
> unnecesarily complicates things, in my opinion.
Better to rely on org-entities and the way entities are treated so far.
> 2. The escape sequence must itself be escapable, wherefore I propose
> to give the backslash special meaning in front of the string
> "vert". Specifically:
>
> a. An even number of consecutive backslashes followed by "vert"
> stands for that number of backslashes divided by two followed by
> "vert".
>
> b. An odd number of consecutive backslashes followed by "vert"
> stands for that many backslashes integer-divided by two, followed by
> "|".
>
> For example, "\vert" exports to "|", "\\vert" to "\vert", "\\\vert" to
> "\|", "\\\\vert" to "\\vert", and so on. Obviously, upon importing,
> the reverse of the above will be carried out.
I would not take that route -- from experience, escaping espace
sequences can drive you mad, and all this is not intuitive for users.
I would simply convert entities by default and use a special table
cookie in lines where you do not want the conversion to happen.
For example:
| Header 1 | Header 2 |
|----------+----------|
| \vert{} | ABC |
=> convert to "|"
But:
| | Header 1 | Header 2 |
|---+----------+----------|
| \ | \vert{} | ABC |
Don't convert. The "\" char is free and a good choice here.
--
Bastien
next prev parent reply other threads:[~2012-12-31 9:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-26 4:32 Bug: Table export to [tc]sv doesn't convert \vert [7.8.11] Nathan Trapuzzano
2012-12-28 17:26 ` Bastien
2012-12-30 1:25 ` Nathan Trapuzzano
2012-12-30 9:00 ` Bastien
2012-12-31 4:01 ` Nathan Trapuzzano
2012-12-31 9:30 ` Bastien [this message]
2013-01-02 21:50 ` Nathan Trapuzzano
2013-01-03 8:57 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87obhao9fa.fsf@bzg.ath.cx \
--to=bzg@altern.org \
--cc=emacs-orgmode@gnu.org \
--cc=nbtrap@nbtrap.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).