On Fri, 7 Feb 2020, Sven Schreiber wrote:
Am 06.02.2020 um 20:19 schrieb Allin Cottrell:
> On Thu, 6 Feb 2020, Sven Schreiber wrote:
> > Am 06.02.2020 um 12:35 schrieb Riccardo (Jack) Lucchetti:
> > > <hansl>
> > > string sep = $windows ? "\" : "/"
> > > </hansl>
> > >
> > > gives an error, because the backslash is considered an escaping
> > > character. This breaks the xy_color packages (and possibly some more).
> > The thread in December "problem with sprintf in ternary statement"
> > related. Allin fixed a bug there by removing a special-casing treatment
> > of \" , but this may be a side effect.
> OK, I've had a further go at fixing this in git. It seems there
> _was_ a rationale for the old special-casing of backslash-quote in the
> conditional assignment context, but it should be turned off whenever
> the sub-context is sprintf().
Could you elaborate on this? In principle it seems that it only matters
whether we have a string literal or something inside sprintf. (Because
as per the doc the meaning of a backslash changes.)
I don't really understand why the ternary statement context is special
at all - OK I can understand it is more difficult to parse, but the same
complication would arise in some other syntactical constructs, no?
The format string for sprintf() is very special and has its own
handler. In most uses a line of hansl that calls sprintf gets passed
on to the special handler straight away. When an sprintf call is
embedded in the conditional assignment context, however, we have to be
able to pick it out, extract it, and that's what can be tricky.