Post by Stefan on Dec 11, 2020 7:43:42 GMT -5
I submit the following for your consideration.
The KEYMAP command section has no reference link(s) to any of the keyboard primitive sections (shown in Appendix), e.g
Introduction to Keyboard Primitives
Index to Keyboard primitives
List of Keyword Primitives
Users would start with HELP KEYMAP and then wonder how the mapping actually works.
The OPTIONS command section has no reference links to the various subsections, e.g. OPTIONS GENERAL, OPTIONS FILE MANAGER, etc.
I appreciate that the 'Contents View' lists them all under 'Customizing SPFLite', but they should be linked from the OPTIONS help page also, as users would start with HELP OPTIONS.
On the OPTIONS GENERAL section, the discussion about INVALID characters is confusing.
The discussion for Invalid characters for P'.' Literals, suggest that the user can freely choose which characters are considered 'invalid'.
A user-considered 'invalid' character that exists in the screen font is perfectly fine to display ASIS.
But the Display char. for invalid characters section defines 'invalid' as "... a character ... which is NOT defined in the current screen font".
Such a character is essentially 'invisible' unless replaced by some symbol.
I have this set to ? (question mark) but I have NEVER seen it used. I use the RASTER font which has no symbol for x'81', x'90' and x'A0' but each of those shows as a blank.
Under what circumstances does SPFLite actually display the replacement character?
Or is it a case that the above 3 chars ARE in the RASTER font, but represented by a blank?
In any case, the two concepts of 'invalid' are not the same thing. IBM used the word 'invalid' because many codes broke a 3270. One could argue that neither is 'invalid' for SPFLite.
Perhaps the former would be better described as a 'special' or 'user defined' character, and/or the latter as a 'unknown in font' (or something more elegant!) character.
The OPTIONS - SCHEMES section shows each scheme in, what I assume is, a default colour.
But at least since release v2.0.20255, SPFLite builds a virgin CFG file with no colours in the scheme, except a pale blue for Normal text Lo intensity and the pyjama paper background.
This renders all AUTO colourisation files inoperative.
The AUTOCAPS section states that "...when the file is saved, the uppercasing will be 'finalised' and written to the output file. So what you see is what you get."
This is ONLY true if the relevant data is TYPED-IN or appears on a line which was otherwise 'touch-changed' by the user.
It does not apply to data that was 'loaded' when the edit session started.
However, the AUTOCAPS statements in an AUTO colourisation file will 'capitalise' relevant words at file-load time so they appear in capitals even though they were loaded in lower case.
So you don't necessarily get what you see.
The CAPS command section states that "when CAPS ON is in effect ... new characters ... will appear in the "Text - High-Intensity" font color."
I have not experienced this, ever. So I assume this is no longer the case.
The MINLEN command and PRESERVE command sections could usefully include a 'Also see' reciprocal link to each other.