ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <pragma@wxs.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: Permissible characters in ConTeXt reference labels
Date: Thu, 18 Sep 2014 00:18:08 +0200	[thread overview]
Message-ID: <541A08A0.1010002@wxs.nl> (raw)
In-Reply-To: <CAE4-1rWNfBh7A3sRgSs2xV61Pc-jqDXY1DcO9_hcSL5AsgGaVA@mail.gmail.com>

On 9/18/2014 12:06 AM, Mark Szepieniec wrote:
> Bump...
>
> If it's not too much trouble, I would greatly appreciate some feedback
> on this before I propose it to be merged into pandoc; even a "looks good
> to me" from one of the ConTeXt gurus would be very helpful.
>
> Thanks in advance,
>
> Mark
>
> On Tue, Sep 9, 2014 at 12:20 AM, Mark Szepieniec <mszepien@gmail.com
> <mailto:mszepien@gmail.com>> wrote:
>
>     I'm trying to fix a problem in pandoc (see
>     https://github.com/jgm/pandoc/pull/1589) where it doesn't properly
>     sanitize the reference labels in ConTeXt output, causing errors
>     during compilation when a label contains '#' for example. Note that
>     this sanitizing is needed in addition to the regular backslash
>     escaping used for control characters: '\#' is still illegal in a
>     label for example.
>
>     In the sanitizer function I'm writing, I'd like to properly escape
>     all illegal characters, but I couldn't find an explicit list of
>     allowed or illegal characters. Based on some testing I've conducted
>     (see attached file), I've arrived at the following set:
>
>     \#[]",{}%()|=

it depends on where these characters end up in

#  : always tricky as it denotes an argument, so escape
[] : depends if it gets fed into a macro that uses [] as delimiters
{} : only an issue when not balanced
%  : escaping needed as it's comment otherwise
() : depends on where it ends up, like []
|  : is special in context so needs escaping
\  : of course that one needs escaping

>     1) Does this look like a reasonable set? Are there other characters
>     or sequences that should be included, or are worth testing?

keep in mind that escapes should end up unescaped at some point

>     2) I was told (see
>     https://groups.google.com/forum/#!topic/pandoc-discuss/tYpXMUkmbEY)
>     that if the characters " and , didn't work, it would count as a
>     ConTeXt bug, is there any truth to that? Please let me know if any
>     further info is needed on my part.

well, define bug ... one can say the same of < and > in xml -)

if the result ends up in a comma separated list then , can be an issue 
but one can always wrap an argument in {} to hide that

>     3) Does anyone see issues with this general approach? I'm relatively
>     new to ConTeXt, so I might be missing either a huge problem, or an
>     obviously easier way to do this.

i don't know ... i never used pandoc input

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
                                              | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________


  reply	other threads:[~2014-09-17 22:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 22:20 Mark Szepieniec
2014-09-17 22:06 ` Mark Szepieniec
2014-09-17 22:18   ` Hans Hagen [this message]
2014-09-18  2:26     ` Aditya Mahajan
2014-09-18 12:39       ` Mark Szepieniec

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=541A08A0.1010002@wxs.nl \
    --to=pragma@wxs.nl \
    --cc=ntg-context@ntg.nl \
    /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.
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 NNTP newsgroup(s).