At 11:59 AM +0900 9/8/11, Philip Spaelti wrote:
>On 9. Aug 2011, at 11:01 , Robert B. Waltz wrote:
>
>>  I'll tell you why it's a mess: ANY character preceded by \ should 
>>be treated as a literal, simply for consistency. I'm pretty sure 
>>this does not work, because of the odd results I've been getting. 
>>Unfortunately, I haven't yet identified the exact command causing 
>>my problems, but it appears that, somehow, a \t is being treated as 
>>a literal t!
>
>With all due respect what you are saying here is inconsistent. You 
>want \[char] to be treated as a literal and then you complain when 
>"\t" is treated as a literal "t" ;-)
>
>Of course "\" is the escape character which means that characters 
>following it are usually treated in a non-literal way. Only special 
>characters should (must) be treated literally after a backslash. NWP 
>does indeed do this correctly, to my knowledge. And "\t" should of 
>course be a tab, which it is. (And enclosing it in double quotes, 
>should just cause interpolation, i.e., turn it into an actual tab, 
>so this shouldn't cause a problem.)

Beg to differ: Nearly all regex engines use a plain dot to mean 'any 
char except line break', and slash-dot to mean a literal full stop 
(or if you like, period).
If Nisus have done this deliberately (which I doubt), they are 
seriously out of step with convention.
See here: http://www.regular-expressions.info/refflavors.html

The idea of an escape sequence is implementation-specific. The idea 
is to escape the usual meaning of a char 
_within_your_program_environment_.
That can mean a usually literal char (such as t, b, n, r, s, ...) 
acquires a special meaning when escaped. And if your program usually 
applies a special meaning to a char (such as, maybe, <return>, '[', 
'\', '?' and '.' ) escaping it will return the literal meaning.
Consistent this has never been (nor could it be).

..AD