Insert POV character in chapter titles

[magicalskye]

When building the projects, the only variables offered for automatically creating the headlines and the title, and various numberings.

But in many books, including the ones I write, it makes much more sense to use the POV character as the chapter title. Many popular published books are formatted like this.

Within novelwriter, it makes 0 sense to actually put just the character name as title, as this makes the document structure completely useless, everything is just Alice Bob Alice Bob Alice Bob…

You can set the name of the document as different from the # title, but the title is what’s used for building the structure view, and the structure view where you can show different variables really HAS to have descriptive titles in it to be useful.

Which means that the way I use this tool, the scene titles I set are for my sanity only, and will need to be replaced in the actual manuscript.

So it would be really, really cool to be able to insert more variables into the headlines, instead of having to edit that all after building, because after building, you also don’t have the variables available anymore, so it’s really a hassle to get that right. Currently i use “character name - title” as naming scheme for the scenes but when actively working on the project, that scheme makes the titles so long that they take up half the screen on the vertical monitor that i write on.

It doesn’t ruin the fun of using this neat little tool but I feel like some better options here would make a nice improvement.

Thank you, and wishing everyone a wonderful day

[vkbo]

The build tool will be completely replaced in the next version (2.1). You can follow the progress in #1269, and I posted a video in there that shows some of it. The tool will be updated first, and in following releases, more and more of the features listed will be added. The new build tool was a huge rewrite, so it has taken a while. It is almost ready.

Anyway, it would be fairly easy to add a new field that picks up the POV character. However, what would you want to pick up? The tag or the title of the note file where the character is defined? Perhaps both would be an option.

Perhaps the best approach here would be to add a new setting in the character file called @displayname to allow you to set a value that can be used for such things.

Sounds like a sensible implementation? Hope that made sense.

[vkbo]

I like the idea anyway, and have been thinking about it myself. I've labelled it as a "planned" feature right away. We just need to figure out how the user should access it.

[magicalskye]

yes, i think a displayname variable would be a great solution, but certainly not the only possible one! very excited for the new version, thank you very much

[vkbo]

I am working on this implementation now.

I've added a way to inject Point of View character or Focus character into chapter and scene headings. However, as discussed in this thread, the tag name itself may not be on the format you want injected into the chapter title. So there needs to be a way to set a different value to be used in titles.

As I see it, there are two options on how to implement it that are both appealing.

Option 1: Allow the @tag definition to take a second argument

# Character Note for Jane Smith

@tag: Jane, Jane Smith

Text ....

The second argument here is optional, and if it is not set, the first argument is used to populate both purposes. When you generate a manuscript with the chapter format:

Chapter {Chapter}: {Char:POV}

The title will render as:

Chapter 1: Jane Smith

I've already implemented this, with syntax highlighting, but I'm not sure this is the best option. It currently looks like this:

Option 2: Add a @display definition that overrides the display name

It would look something like this in the editor:

# Character Note for Jane Smith

@tag: Jane
@display: Jane Smith

Text ....

This is a bit more complicated to implement in the code, because if @display is defined before @tag, there is nowhere to store the data until the @tag is encountered, so it requires more convoluted parsing logic. That is not really a show stopper. I can figure it out.

Discussion

I am uncertain if Option 2 is clearer than Option 1 or not. However, implementing Option 1 means enforcing the rule that only one tag can be set per heading. Currently, additional values passed to @tag are just silently ignored by the parser, and highlighted as an error in the editor. So if anyone's set multiple arguments anywhere, the second one will suddenly have a meaning, which may cause unexpected results in the manuscript build.

The upside with Option 1 is that it is easy to implement because the values are processed together. The difference in syntax highlighting also makes it clear they are two different things. You still have to check the documentation to learn what the difference is though. I have generalised it into "value" and "optional" arguments in the parser and highlighter, so this can possibly be used for other things later.

A concern I have with Option 1 is that it uses a comma as a separator both for regular values and optional values. Maybe there should be a different syntax? Should we instead use @tag: Jane | Jane Smith as the format for instance?

Edit: I'm kind of liking this syntax too ...

[vkbo]

Maybe @johnblommers, @tmarplatt, @HeyMyian or any of the other active people who often provide feedback want to chime in on this issue?

[tmarplatt]

The way I see it, using keywords for entering project settings is in power user territory. I think this will be too obscure a feature with much useful potential. Unless you're adding yet a new GUI control for it.

That said, Option 1 is hardly less obscure. And: what if the author wants a comma in the display name? I guess you ignore all comas after the first match.

(At some point you'll have to consider implementing a comprehensive metadata editor for notes. Something that takes away the mental weight of managing so many details that are relevant to the final manuscript.)

[vkbo]

I share the concern about complexity creep. The tags and references syntax is already a barrier for new users, but is fairly straightforward when you get past the barrier. It was always intended to be simple to avoid the forms other tools have for the same purpose.

The auto-complete feature added last release should help for users with a lot of complex tags and references as well. The system was never intended to be used in as detailed a manner as some users seem to do, but then some writers really like to get into the details of their story. I'm fine with supporting that as long as it isn't required complexity, which it currently isn't. You can still write your novel by tagging characters by the name used in the story, which should be easy to remember, and format with basic Markdown.

Now, putting POV character into chapter titles is a standard practice. If your character tags are the same as the name they go by in the text, there is no need to modify the tag at all. By default, @tag: Jane will show up as "Jane" in the chapter title. It is only if you have some added complexity already, like @tag: MainCharJane | Jane you really need the new option. Using commas in tags and references has never been possible, and still isn't.

So while I agree with the complexity creep concern, the basic feature here is not complex. The header formatter is already a point-and-click form where chapter numbers can be added, and now it has two new options for POV and focus character. The information is inserted using existing meta data by default. No added syntax is needed to get it to work.

As for the point about meta data editor for notes: There is only a single meta data entry in a note, and that is the tag. You can add references in notes too, but they aren't used by novelWriter for anything.

[vkbo]

The way I see it, using keywords for entering project settings is in power user territory.

Just wanted to clarify this point too, depending on what you mean by "project settings" here. The formatting is controlled in the Manuscript Build tool. The only new keyword syntax here is to be able to allow an alternate form of a tag, if, and only if, it is needed. Project settings will never be a matter of commands. Only meta data.

Edit: To clarify, this is all you need to get the names into chapter titles.

[vkbo]

I've merged the feature for now. The main part is the insert feature itself, as shown in the screenshot above. This part is the only way to do this anyway. As for the "display name" optional feature, it can be changed if it isn't working. Up until the final release of 2.3 anyway.