From: "Thomas A. Schmitz" <thomas.schmitz@uni-bonn.de>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: lpeg substitution
Date: Wed, 12 Aug 2009 11:04:30 +0200 [thread overview]
Message-ID: <61F11BB9-7B02-4907-B0E7-4BD4E2E67271@uni-bonn.de> (raw)
In-Reply-To: <4A827E1B.6050608@wxs.nl>
On Aug 12, 2009, at 10:32 AM, Hans Hagen wrote:
>>> if there is more demand for that i can consider making a
>>> substituter that operates on the node list in an early stage; that
>>> way it is controlled by attributes and there is no interference
>>> with macro definitions, reading modules and such
>> Macro interaction may be an issue, but I believe it is still better
>> for transliterations to work on the actual input strings or on
>> tokens.
>> For example, you may want to run macros (like \delimitedtext) on the
>> converted output.
>
> my main concern with that is that one then needs to control
> precisely where to apply such translations; for instance turning a<
> into something else might also mess up math and adding all kind of
> extra checking and housekeeping (for instance when loading modules
> or whatever in the middle of such a conversion)
>
> of course when the to be converted fragments are tagged it's trivial
> to use lpeg and avoid \cs's
>
> btw, i think that delimitedtext would work anyway as we only replace
> "glyph a glyph<" by something else then
>
> anyway, it all depends on the task and hopefully unicode will solve
> all our problems (and not introduce more)
Well, in my case the fragments are already delimited, so it's
relatively easy. However, I wonder whether there are many applications
for this. I don't see too many, but maybe I'm wrong. From my POV,
there is no need for this in the core, but maybe others see more usage.
Thomas
___________________________________________________________________________________
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 : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___________________________________________________________________________________
prev parent reply other threads:[~2009-08-12 9:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-11 9:34 Thomas A. Schmitz
2009-08-11 10:59 ` Hans Hagen
2009-08-11 11:21 ` Thomas A. Schmitz
2009-08-11 12:35 ` Hans Hagen
2009-08-11 15:14 ` Thomas A. Schmitz
2009-08-11 22:01 ` Hans Hagen
2009-08-12 6:51 ` Taco Hoekwater
2009-08-12 8:32 ` Hans Hagen
2009-08-12 9:04 ` Thomas A. Schmitz [this message]
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=61F11BB9-7B02-4907-B0E7-4BD4E2E67271@uni-bonn.de \
--to=thomas.schmitz@uni-bonn.de \
--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).