Warnings about keywords

[R3dH00d1988]

On my Mac build, whenever I update the index I get the following warnings in the terminal window:

WARNING   Skipping keyword with 1 value(s) in 100de98712736
WARNING   Skipping keyword with 1 value(s) in 40a8e442cbabd
WARNING   Skipping keyword with 1 value(s) in 1de2686af2bb9
WARNING   Skipping keyword with 1 value(s) in 9627c91bcb648
WARNING   Skipping keyword with 1 value(s) in b0ce2e9a9fbbc

Is there any way to figure out what is causing those warnings? I'm using the following keywords at the beginning of each of my scene files, along with the corresponding root folders (Character, Plot, Locations, Timeline):

@pov
@char
@plot
@location
@time

Thanks.

[vkbo]

This warning is issued when the index finds a line in your file starting with an @ character, but the line doesn't parse as a correct keyword/value set. There is a minor bug in that warning. It should say Skipping keyword with 0 value(s) in ... instead of 1, as you have not actually referenced any tags in the example you provide.

A proper point-of-view tag looks something like this: @pov: Jane where Jane refers to a file in the Characters folder with a line like this @tag: Jane. That is, each reference keyword should be followed by a list of tags, and the tags must be defined in a note file placed in the correct type of root folder.

I realise that the tag and reference system isn't immediately obvious to new users. The @pov, @char, @tag, etc. are basically commands, but you have to tell the commands what to connect to. All references to Jane must point to a single instance of a tag Jane. The syntax highlighter will show a green line under the tag if it is undefined or has other issues. If they are correct and identifiable, the tags become clickable in the viewer, or you can control/command-click them in the editor to open the note they refer to.

It is explained in the documentation, here. I'm happy to improve it if the documentation is unclear.

I'm considering adding a GUI tool to assist in defining these tags. A point-and-click approach that can work alongside just typing them. The benefit of just being able to type them is that it's quicker when you are used to them and want to edit them on the fly while writing.

You can create a sample project from the "New Project" tool and have a look at how it's intended to be used. Here's a screenshot:

[vkbo]

Also, you shouldn't have to update the index manually unless something has gone wrong (and occasionally an update of novelWriter will require it). Files are indexed automatically when they are saved and the indexed cached between writing sessions.

[R3dH00d1988]

Thanks. I do have values declared after each keyword; I just didn't include them in the post.

But, as you can see, they have the green underline meaning there's a problem, even though I have corresponding files in the root folders:

[vkbo]

Ah, I see. That's strange, because the warning in your initial post indicates that you only have the keyword and not the tag itself on a line somewhere. That's the only way to produce that exact warning. Maybe you have a bare keyword somewhere else in your project that is causing that warning. The lines from your screenshot shouldn't print a warning at all. Undefined tags are silently ignored and instead indicated by the green error line seen in the image.

In any case, "Cash" here is intended to point to @tag: Cash not a document labelled "Cash", so you need to add the tag to the content of that file under the relevant heading. You can have multiple tags in the same file as long as they are under different headings. (See docs here.)

The index essentially just keeps track of all headings in your project (any line staring with #) and keeps a record of all tags and references under each of them (any line starting with @). There isn't a lot more to it than that really.

[R3dH00d1988]

Ah. Now I get it. That was the problem. I created a separated file for each keyword.

Thanks for the help.

[vkbo]

Fantastic.

I took the chance to write down some of my own ideas on how to improve this feature. I added it as issue #823. Feel free to add suggestions. I've been meaning to improve this for a while now, and I hope I will get to it soon.