Hi, On the verge of checking in a quick fix for the \h"..." TODO, it occurred to me that we either don't want to accomodate for pod2man badness OR something more subtle's at work. \h"..." is specifically disallowed by groff(1). So I searched in the groff source. Behold! In groff.c's input.cpp, we see several escapes (h, H, N, S, v, x) directly condition their enclosing markers on the first character (see get_delim_number()) while others do so indirectly. These set the end marker on the first character given that it satisfies the token::delimiter() method (or whatever is C++'s name for an object function). The delimiter() function (also in input.cpp) allows any character but a certain ASCII subset and whitespace. groff(7) mentions the apostrophe, but it can much much more. Question is: do we want this behaviour? I'd say we do, but as it's somewhat intrusive, I want some consensus before committing. Either way, I do NOT suggest that we outwardly document this. Note that this also fixes the situation where some non-\N escapes were being assigned the NUMERIC identifier, which is only used for \N. I also removed the check for \N numbers, as this is done again later. Thoughts? Kristaps