Post by Stefan on Oct 30, 2021 13:22:26 GMT -5
George,
I completely revised this post to simplify the diagnosis.
I attach some files to help you reproduce what I see.
These files will demonstrate some weird Auto-coloring effects.
Supporting Files.zip (10.47 KB)
TEST.REX
REX.AUTO
CFG: ODEFAULT section
CFG: REX profile
(1) There is a difference in COMMENTn colorisation between version 21247 and 21307.
Version 21247 displays TEST.REX as intended like this:
Version 21307 displays the same file like this:
Please ignore the kaleidoscope on data lines 23 to 25 for now!
I do note that v21307 pops up a window stating that '*' is used in DELIMNS as well as COMMENT4.
I removed it from DELIMNS but the REXX comment lines are still coloured incorrectly.
In the case of REXX comment lines, the '/**' sequence is not recorgnised 'as one string', as evidence by the '/' and '**' elements being coloured independently.
The trigger sequence '/**' is defined by COMMENT2 statement in the AUTO.REX file
Experimentation with the AUTO file shows that the '/' is given the colour defined on the COMMENT1 statement in the AUTO file.
The '/**' sequence does implement 'comment' processing (ie: no further highliting is done) but the line appears in (Text Lo Intensity) Green, not (12) white.
(2) Now the Kaleidoscope on lines 23 and 25
I first tried a RESET ALL COLOR command. It does change the colors on lines 23 and 25, but the lines remain incorrectly coloured.
A bit of experimentation showed that the key positions appear to be columns 4, 5 and 6 of lines 23 and 25.
Overtyping any of those colums with symbols other than '*' causes changes to the fore- and/or background colour of other characters further along on the line.
The REX.AUTO file also contained the statement: WORD 2 *
Removing this and reloading the does not affect this behaviour.
I expect that whatever the cause for this, is also responsible for the errand red highlight in column 89 on line 11.
(3) Separate pop-up windows for every AUTO statement error
This leads to 2 issues:
(a) SPFLite can crash.
I (lazily) build the AUTO files from the relevant language reference manual and consequently often have many duplicate entries.
In the past, this just meant that the first entry 'wins' the colorisation 'conflict'. No big deal.
Recently, opening a REXX file, I saw several dozen pop-up windows.
I don't know how many exactly, but noted there was duplication, e.g. the same WORD entry was mentioned several times.
I worked my way through clicking <OK> but eventually SPFLite brought up the crash window and after I acknowledged that, SPFLite died.
In the past, this just meant that the first entry 'wins' the colorisation 'conflict'. No big deal.
Recently, opening a REXX file, I saw several dozen pop-up windows.
I don't know how many exactly, but noted there was duplication, e.g. the same WORD entry was mentioned several times.
I worked my way through clicking <OK> but eventually SPFLite brought up the crash window and after I acknowledged that, SPFLite died.
(b) The user is effectively forced to acknowledge each pop-up warning before s/he can do anything else with the file being opened.
And there is no list afterwards to tell the user which statements need to be corrected in the relevant AUTO file.
Maybe a single pop-up window to alert the user to irregularities within the AUTO file statements would suffice.
The user can acknowledge that and the file is opened for use.
The details of which AUTO statement(s) caused an issue can be presented in a another way, for example:
- Add LNOTE (or even better =WARN>) lines to the file being 'opened' for editing to list each issue found.
These lines would be added at the 'Get_TopScrn_LPtr' line to allow for any 'STATE ON' positioning.
These lines would be added at the 'Get_TopScrn_LPtr' line to allow for any 'STATE ON' positioning.
- Write the 'issue list' into a named clip board, e.g. 'AUTOERR'
Then queue (ala 'SPF_POST_DO') a CLIP AUTOERR command to cause the messages to be shown to the user in another tab.
Then queue (ala 'SPF_POST_DO') a CLIP AUTOERR command to cause the messages to be shown to the user in another tab.
- Use a larger window, similar to displaying 'multiple messages' resulting from a macro execution (would ned to be scrollable though)
(4) COMMENT 'trigger' strings and DELIMS characters
The new validation code warns about duplicate symbols appearing in the 'trigger' string on a COMMENTn statement and in the DELIMNS definition.
Logically, a COMMENTn 'trigger' string must appear 'asis', (optionally in a specified column) to identify a language comment.
So the string should be treated/matched 'as a whole', not individual characters even if it consists of non-alphanum symbols.
I note that there is no 'duplicate' warning for these two entries:
COMMENT4 11 REM 1
AUTOCAPS 2 REM
Enforcing rules that prevent multi-purpose characters like (quote) or maths symbols like *, +, -, etc from also being delimiters can cause erroneous colorisation as well.
If, for example, * cannot be a delimiter because it is part of a /* */ sequence in a COMMENTn definition, the statement X=3*LEN(string$) fails to colorise the numeric literal and the LEN function.
(5) QUOTED enhancements
The enhancement may allow other delineation characters to be specified, but only at the expense of the DELIMNS character pool.
The warnings feel especially strange when QUOTED is used without parameters as the user has not explicitly duplicated anything in the AUTO file.
The enhancement may allow other delineation characters to be specified, but only at the expense of the DELIMNS character pool.
The warnings feel especially strange when QUOTED is used without parameters as the user has not explicitly duplicated anything in the AUTO file.
The effect is worse for characters like single quote ' which in BASIC has muliple uses. It could start a language comment or a quoted string.
AUTO colorisation trips over statements that include more that one type of quotation mark.Example: It will fail to recognise the language comment at the end of this statement
cmdRC = SPF_Cmd("FIND R'"+what$+"' FIRST") ' Look FOR a matching entry
and colorise/capitalise the FOR as a BASIC instruction and display the rest in (Text Lo Intensity) Green.
Remove the single quotes from within the double quoted strings and colorisation works perfectly.
But why is the 'QUOTED' logic even concerned with the single quotes within the quoted strings?
Whilst scanning the line, and having met a double quote, should it not ignore everything until the next double quote?
Hope this hels you sort teh gremlins.
Apologies for this being such a long post.
)
