[Resolved] "Character & Dialogue" formatting spills over

[November_Sierra]

Working on a custom script format, I noticed a strange behavior. Not sure if this is a bug or a technical limitation or my lack of understanding. Maybe someone else knows what’s going on there.

The behavior is easy to reproduce with the built-in “Stage Play (UK)” format. Out of the box, it’s set to:

Which results in:

Great. Now, if I remove the “:” (the TAB gets still inserted!), like this:

The result is somewhat unexpected:

Still “all caps”, and only up to the correct place (“first tab”), but the bold formatting goes on.

Okay, so for the final step I manually clean up the script like this:

And for testing purposes add “Italic” formatting in the script settings:

Which encourages Scrivener to reformat the script. And surprisingly:

That is correct. Neither bold nor italic “spill over” into the dialog after the character name. But that doesn’t work when typing it. Shouldn’t it be the same behavior? Any ideas why?

EDIT: All right. Flagging it as a bug.
Scrivener 3.3.3 (15931) on MacOS Sonoma 14.0 (23A344)

[MimeticMouton]

That does not seem to be the proper behaviour, no, but I’ll have to investigate how this is working internally. In the meanwhile, an alternative way of working around it is to tick the “Allow tabs” option in the script settings Tab/Return pane. That does remove the ability to use the Tabbing on an empty line or Tabbing after typing features for the Character & Dialogue element, but it would allow you to “manually” insert the tab, so to speak, and that seems to work to properly cut off the formatting when you’re styling to the first tab.

[November_Sierra]

Thanks for investigating!

You’re right, “Allow tabs” at least stops the formatting, as intended. I didn’t think of trying that. But the lost functionality (e.g. jumping into “Scene Action”) creates more of a hassle than hitting ⌘ B. I’ll probably resort to fixing it in post-processing until this issue is resolved.

[MimeticMouton]

Another option would be to add a unique character delimiter back into the insert-after-typing space, to come before the tab as the colon used to do, then remove that via compile replacements.

[November_Sierra]

Yeah, I’m experimenting with that, too. It seems that any character – other than the tab, ironically – stops the formatting, even a zero-width-space (U+200B).

[KB]

I have this fixed for the next update (3.3.6).

The problem was down to error checking. The code works like this:

1. Typing…
2. Text change reported by the text system.
3. Custom code checks for tab insertion.
4. If there was a tab insertion, replace it in the text with whatever is set in the script settings.
5. Text change reported by the system.

So if the settings are set up to replace a tab with only a tab (and nothing else), then the above can result in an infinite loop, and thus a software hang. My previous fix was to bail if only a tab was inserted, but that meant that the “reset formatting” code never got triggered in this situation. I have altered the code to let the above go through once only and only bail after that, so that the hang is avoided and the formatting gets reset as expected.

All the best,
Keith

[November_Sierra]

Wow, that was damn fast, Keith! Thanks for the in-depth explanation, too. I’m always keen to learn how things work and why (or why not).

[KB]

3.3.6 is now live (although the site still says 3.3.5 - that will be updated later, when Ioa is up and around), and contains this fix.

Thanks and all the best,
Keith

[November_Sierra]

Well, well, well… it works! Thanks a lot, Keith!