On 17.11.25 23:43, Dave Kemper wrote: > And this would work to set its end-of-sentence property--but it would
> have the side effect of overwriting the flag (4) that \[em] already > had set. ... > The .cflags request only overwrites all existing flags; it does not > have a syntax to preserve flags while adding a new one. Instead, an AND and an OR operation seem a minimal implementational requirement, to meet your needs. Would comfortable syntactic sugar be to simply replace 's' with [+-], to explicate that the crude bulk overwrite is now a bitwise set/clear? I.e.: .cflag+ [flag] target .cflag- [flag] target Then replace one implementing line of 'C' with two cases, something like flags &= ~(flag) ; flags |= (flag) ; ISTR that this flag structuring already exists: #define thisflag (1<<4) #define thatflag (1<<9) for a miscible flag set. If .class needs to set/clear multiple flags on entry/exit, then I'd almost be tempted to e.g.: #define Class_alpha (flagA | flagD | flagG) and stuff that through .cflag[+-] for two for the price of one. (OK, that wouldn't implicitly handle exit where two classes shared a flag or two. Non-overlap would be a prerequisite for a practicable implementation of such (over)simplifiction. Currently we have a big hammer, but not every problem is a nail. OK, backward compatibility, and all that good stuff, so just add the new one alongside, for zero hysterical raisins? Well, that's hopefully relevant, if I haven't misunderstood the issue, or missed a hidden nuance - neither entirely improbable. (The less one knows, the simpler things appear.) Erik
