Werner LEMBERG <[email protected]> wrote: |> Well exactly that was however the initial problem: while testing the |> manual of the MUA i maintain i got three occurrences of similar |> errors for \A'' on the result of a ".substring 0 1". | |Ouch :-) Not having an `interned' representation can be advantageous, |but here it's definitely a problem... | |> Note how you cannot even say \A'\*[a]\*[b]', since the result seems |> to get expanded on the fly and breaks \A'' if that ends up as "\[". |> So this is anything but robust and as such defeats the sole purpose |> of \A''. | |Yes, it can't handle backslashes because they are always handled |before the request sees them. Note that you want expansion of \*[...] |and \n[...], but at the same time you want that a solitary `\[' |doesn't cause an error. How shall this work?
Hmm, ok i see now what you mean. I don't know the code in question yet, but should i ever come up with a nice solution i will open a regular ticket with a patch for groff(1), too (if possible). ..I think i would implement such a thing by parsing the construct and then recursively expanding the bounded content until no more expansion is possible, finally checking the result: Since \A'' is ment to check if that final result is a valid identifier i think (now that) i wouldn't care wether \[ is "something incomplete" in other contexts. As above. |I can imagine to add another escape sequence (or request) that accepts |a string register as an argument, checking its contents. Cf. the |`dei' request. That would be another solution. I'm just looking at ChangeLog.117 right now, but don't understand the complexity behind the problem yet (what i hope). That'll take time. And as above. :) Thanks, Ciao, and have a nice weekend.. --steffen _______________________________________________ bug-groff mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-groff
