ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
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
___________________________________________________________________________________


      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).