"Embedded" Keyword Comments

Rules for comment storage

PRIMER faces the problem that while it stores keyword data, and knows which include file this occupies, it does not "remember" where (at which line) a particular keyword occurred. In fact it may often re-order the data in a keyword deck when it writes it out. Therefore in order to be stored comments need to be associated with a keyword, and PRIMER takes this a stage further by remembering exactly which line in a keyword each comment is associated with.

Consider the following fragment of a keyword deck, which has been artificially separated into sections:

"Embedded"

Shown in red

Saved by PRIMER

These comments lie between the *Keyword header and a data line, or between sucessive data lines.

PRIMER associates these with the line of data that immediately follows the comment, and saves them in that location on that keyword.

For example the comments

" $ This part used to be steel ... "
and
" $ This change was made ... "

Are both associated with line 1 of Part 5. And the comment

" $ This part uses the original ... "

is associated with line 1 of Part 6. Any number of comments may be associated with any data lines, and they are stored as text strings in the order in which they appear.

Comments stay with their definitions so if, for example, Part 5 in this deck was moved to a different include file it would take its embedded comments with it, and they would appear above the relevant data line.

If the keyword data is modified so that its data lines are reformatted then comments still associate themselves with line N of the definition, regardless of what that might contain. In other words association with a given line of a definition is "dumb" and is not related in any way to the data that line contains.

These comments can be visualised in PRIMER , and modified using the Text edit capability.

"Special"

Shown in blue

Ignored by PRIMER

If a comment line starts with a dollar followed immediately by a colon, " $: ", then PRIMER treats this as a special comment that does not need to be remembered. For example the following line in the above is a special comment:

"$:     pid    secid    mid    eosid    hgid"

This syntax is used for data field headers and comment lines such as those listing the items referencing a loadcurve, since these will be regenerated automatically (and may change) each time a new keyword output file is created, so it does not make sense to store them.

LS-PREPOST starts "special" comments with the alternative " $# " syntax. By default PRIMER will also treat these lines as special comments, ignoring them in the same way as lines starting " $: ". To change this behaviour set the preference primer*ignore_lspp_comment to false .

"Free standing"

Shown in dark green

Ignored by PRIMER

These comments lie after the last data line of the previous keyword, and before the *Keyword header of the next one.

PRIMER ignores these comments since they have no fixed association with a particular keyword.

(An exception is made for comments at the top of a keyword deck / include file, which are stored as a property of that file and may be edited.)

On a scalar editing panel

The Text edit button will be shown in light blue, and hovering the cursor over that button will list comments for that keyword.

This example shows the result for Part 5 above.

On a Keyword editor row

If the definition on a row contains comments then a light blue C will be shown on its row button, and hovering the cursor over that button will list them.