\ca, \cp, \va, and \vp are treated the same everywhere

[Gaming32]

The USFM spec indicates that these can only follow \c or \v directly. However, this library allows them anywhere, overwriting any previous instance of them in the current chapter or verse, without any diagnostics emitted for it. You can find an example of this in ESG of the TPI translation.

Looking a bit further into this, however, things seem to reveal that \ca and \va may be used in other places, but then are treated as chars instead of as metadata for the preceding \c or \v.

[jcuenod]

Thanks @Gaming32! I'm not really sure what the best "error-tolerant" way to handle this is.

So I'm working on a branch (#3) that does this by adding a metadata handler. When I process 43-ESGtpi.usfm, this branch produces:

[4982:4985] error: \cp is not valid in this location
[15924:15927] error: \cp is not valid in this location
[18156:18159] error: \cp is not valid in this location
[20800:20803] error: \cp is not valid in this location
[25257:25260] error: \cp is not valid in this location
[33938:33941] error: \cp is not valid in this location
[45494:45497] error: \cp is not valid in this location
[50848:50851] error: \cp is not valid in this location
[57912:57915] error: \cp is not valid in this location

I'm attaching the USJ here: tpi-43-ESGtpi.usj.json. What do you think of this solution?

[Gaming32]

This does seem to have pretty good output. The docs are really unclear as to what's supposed to happen here.

[jcuenod]

I'm hesitant about merging this because I'm not yet convinced by the addition of crates/usfm3/src/metadata.rs. Is this a critical/urgent feature for you?

[Gaming32]

No this is not critical.