PRIMER 22.1

Editing a Single Item

Editing a Single Item

In any scalar (single item) editing panel you can use the Text Edit button to generate a mini-keyword deck containing just this keyword. It is generated from the scratch data currently populating the editing panel, and will contain any comments embedded in the card. (It is also possible to edit multiple items using Text edit on the keyword editor, this is described in Editing Multiple Items Using the Keyword Editor)

Note also that there is a general Text Edit button in the Tools panel that can be used to edit any keyword, not just one in an editing panel or the keyword editor. This is described in Text Edit

An example is given below for a PART, and the default output is split into three sections as annotated here


Section File Contents (continuous text in an actual file)

(1)Header

$ Edit/view data and comments.
$ ----------------------------
$
$ Only lines after *keyword below will be reread by PRIMER. See RULES
$ at the end of this file for details on data and comment editing.
$
(2) Data *PART
sill_swan_neck
$:
pid
secid
mid
eosid
hgid
grav
adpopt

5
3
5
0
0
0
0
$
(3) Rules
$ RULES for editing data and comments in this file.
$ -------------------------------------------------
$
$ Make any changes you wish to the data and/or comments and then save
$ the file under its existing name to update the PRIMER definition.
$
$ Rules when saving changes:
$
$ If you simply 'quit' from this edit this file will be deleted and
$ no changes will be imported back into PRIMER.
$
$ If you make changes to either data or comments then save this file
$ under its current name your changes will be imported back into the
$ current edit panel in PRIMER, and the file will then be deleted.
$
$ If you save this file under a different name, with or without any
$ edits, that new file will remain on disk. Any changes will only be
$ imported back into PRIMER if you also saved them to the original
$ filename, and that original file will be deleted as above.
$
$
$ Rules when editing comments for import back into PRIMER:
$
$ Only comments inserted between the *keyword header and data rows,
$ or in between multiple data rows, will be 'remembered'. Comments
$ before *keyword, and 'trailing' comments below data rows (such as
$ these rules) will be ignored.
$
$ Comment lines (anywhere) starting '$:' will be ignored.
$
$
$ To suppress the initial explanation and these RULES set the preference
$
$ primer*text_edit_show_rules: FALSE
$
$ To turn off data field headers in the file to be edited (setting does
$ not affect the output of headers in normal keyout files) use
$
$ primer*text_edit_show_names: FALSE

Associated *COMMENT data in text editing files.

If *COMMENT cards are associated with keywords then they generally contain meta-data that is related to those keywords. To make this easier to visualise and edit any *COMMENTs associated with a keyword will also be written to the "mini file" used for editing via Text Edit. This topic is covered in more detail under the *COMMENT documentation.

Controlling the output in the file

This default output is verbose and is intended for a 1st-time user. You can control the output using the following preferences:

primer*text_edit_show_rules: true or false Whether or not to show sections (1) and (3) above. Most users who have become accustomed to the rules explaining how this works will wish to use this preference to cut output down to just section (2) only.
primer*text_edit_show_names: true or false Whether or not the field headers (here pid, secid , etc) are shown above each row of data.

Controlling which text editor is used.

By default PRIMER will attempt to use the default system editor.

  • On a Unix/Linux system this may be an editor built into the Window manager system, or if the environment variable $EDITOR is set then this will be used.
  • On a Windows system PRIMER will try Notepad or Wordpad if no explicit editor is defined.

On any operating system you can override these defaults by setting the following preference:

primer*text_editor: < pathname of editor > for example C:\Program Files\Vim\Vim70\gvim.exe

Rules for using the text editor

The text editor operates as follows:

  • A temporary filename containing the keyword output is generated in the directory containing the model. If this cannot be opened, for example because that directory is read-only, then the file is created in a temporary directory instead.

  • The relevant editor is launched to read this file. This is done in a separate thread so that the editor process is autonomous and does not "lock" the PRIMER session in any way.

  • You are free to modify the temporary file in any way you please, or to read new content into it to replace the existing. You can also save copies of the file under different names, and generally do anything you would normally do in an editing session, including aborting the session without changing anything.

  • When you finally exit from the editor the following happens:

    • Any files other than the temporary file that you might have created (by "Save as...") are left unchanged on disk, and are not considered or read in any way.

    • If the original temporary file is unchanged - specifically if its "last modified" time has not changed since its creation - then no further action is taken and it is deleted.

    • If the original temporary file has changed then it is read back into PRIMER via a "mini keyword read" process, and the contents of the file will overwrite the scratch definition in the editing panel. The temporary file is then deleted.

      Inside PRIMER this is done by reading all the file contents into a scratch model, then extracting the first definition of the relevant type (here *PART) from that scratch model and using it to replace the definition being edited. So if you import more than a single definition, or perhaps load different keywords from some other file, all except the first definition encountered of the relevant keyword will be ignored. If there are no keywords of the relevant type (here *PART) in the file, then PRIMER will issue a warning message, the file contents will be discarded and no changes will be made to the definition currently being edited.

      Therefore you can use this method as an alternative way to update keywords, perhaps by cutting and pasting text in the editor from other files. However it is restricted to changing only the current keyword definition, and cannot be used as a generalised method of importing unrelated keywords into the model.

      If you want to read "fragments" of some other deck into this model it is better to use Model Read to read these into a separate model, then Model Merge to merge them into this model. This will permit input of any keywords, and the merge operation will protect you against label clashes.