|
|
Post by Stefan on Jan 15, 2023 18:19:20 GMT -5
Trying to refresh my memory here. There is no mention in the doc, nor in the code of any matching of delimiters between QUOTED and COMMENTx statements. And since Stefan's AUTO file has ' in both the QUOTED and COMMENT statements, I guess the term is indeterminate. Stefan: Send me your AUTO file and MACRO file and I'll have a look. George
I've fixed my MACRO issues by replacing the MACRO.AUTO file statement QUOTED 7 with QUOTED 7 ""
ie, I specify only double-quotes instead of accepting the default of single, double and reverse quotes. I also changed single-quotes in statements like
SPF_Cmd("FIND R'"+what$+"' "+aOccur$) ' Re-enter the original FIND command
to reverse-quotes
SPF_Cmd("FIND R`"+what$+"` "+aOccur$) ' Re-enter the original FIND command
Replacing single-quotes with reverse-quotes ensures that the comment AFTER the statement is recognised, otherwise the single quotes within the SPF_CMD stmt confuses AUTO-Colorisation. It is OK to use single quotes within a double-quoted literal, as long no single-quote-initiated comment follows the statement on the same line.
REXX is different again and suddenly some comments are messed up
My REXX.AUTO file has been workig brilliantly with these definitions: ; SPFLite Colorize file for Object REXX (ooREXX)
;
; Notes:
; 1 (PINK) used for 'Debug' functions to allow easy removal of such
; statements after testing is complete.
;
; 10 (CYAN) used for statement pairs (e.g. FOR...NEXT, etc) to inprove
; visual detection of orphaned singles in the pair.
;
; 9 (STD LO GREEN) used to allow AUTOCAPS/AUTOCASE effect without colour change
;
; Clr Trig Loc
; --- ---- ---
QUOTED 7 ""
NUMERIC 6 ; Numeric Literals
;
COMMENT1 1 --# 0 ; DEBUG & TRACE statement highliter (PINK)
COMMENT2 12 /** 1 ; Multiline comment (WHITE) START
COMMENT4 11 * 2 ; (GREY) Continuation line
COMMENT3 12 **/ 2 ; (WHITE) END
COMMENT5 11 /* */ 0 ; Standard comment (GREY)
COMMENT6 4 -- 0 ; To EoL comment (RED)
COMMENT7 13 SIGNAL 0 ; Error Trap Call (BROWN)
;
DELIMS %&()*+,-/<=>@[\]^{|}~¬; ; Excludes '.' and '_'
Since the latest beta versions, the comment processing is different. The comment on the statement below (between the /* */ delimiters) is not recognised at all. IF "+-"~Pos(col~Left(1)) > 0 THEN - /* IF Col is relative or ""... */
The delimiters and the comment text is simply colorised as if it were normal text. In this case, the "" WITHIN the comment causes the issue. Remove the double-quotes or replace them with two single-quotes and all is well again.
In general. the effects I'm seeing suggest that previously the code checked for comments BEFORE literals and now it does it the other way around.
|
|
|
|
Post by George on Jan 16, 2023 9:33:25 GMT -5
Stefan: The order of checking was not changed, but when comments are spotted, it now does a check to see if the comment ID is between quotes, if so it's ignored. I'll check, maybe that's not working for paired IDs (/* */).
George
|
|
|
|
Post by George on Jan 16, 2023 14:18:47 GMT -5
Stefan: OK, you're really pushing the Attr scan routine, remembering that it doesn't do a full proper parse of the line.
Your sample failing line:
IF "+-"~Pos(col~Left(1)) > 0 THEN - /* IF Col is relative or ""... */
messes up in the new code which tries to prevent a comment ID being discovered within quotes.
Looking at the line, it finds the /* and then looks left and right and lo and behold finds a quote on the left and a quote on the right, therefor this can't be a legitimate start of comment.
I've managed a small change to cope with this, but I'm sure you'll break even that.
We have to face it. As Robert said, unless we do a full, language based parse of the lines, we'll never have a bullet-proof colorization scheme.
The routine does pretty well I think, we just have to be aware of its limitations.
I'm going to roll out a full release which will have this fix included.
George
|
|
|
|
Post by Robert on Jan 16, 2023 14:46:38 GMT -5
post deleted
|
|
|
|
Post by George on Jan 16, 2023 15:57:54 GMT -5
Robert: You have the skills to do this, I don't, and at my age I just have no interest in learning how.
So, with your skillset, redesign CLRLOAD and ATTRSCAN the way they should always have been. Recode them and come back with:
a) A migration routine to move existing AUTO files into whatever new format you require.
b) Re-written CLRLOAD and ATTRScan routines. I'll happily swap them into the main code.
You can't keep trotting out all these solutions, which you well know I am not capable of implementing (but you certainly don't miss the opportunity to point it out anyway).
If you aren't willing or able to actually contribute to coding this, then these complex solutions are just noise.
George
|
|
|
|
Post by Robert on Jan 16, 2023 17:35:57 GMT -5
post deleted
|
|
|
|
Post by Stefan on Jan 17, 2023 4:59:59 GMT -5
Stefan: OK, you're really pushing the Attr scan routine, remembering that it doesn't do a full proper parse of the line. Your sample failing line: IF "+-"~Pos(col~Left(1)) > 0 THEN - /* IF Col is relative or ""... */messes up in the new code which tries to prevent a comment ID being discovered within quotes. Looking at the line, it finds the /* and then looks left and right and lo and behold finds a quote on the left and a quote on the right, therefor this can't be a legitimate start of comment. I've managed a small change to cope with this, but I'm sure you'll break even that. We have to face it. As Robert said, unless we do a full, language based parse of the lines, we'll never have a bullet-proof colorization scheme. The routine does pretty well I think, we just have to be aware of its limitations. I'm going to roll out a full release which will have this fix included. George George,
Let me just say that I don't set out to 'push' the Attr routine, nor do I seek to break yoiur fixes. I'm not deliberately testing SPFLite to destruction.
I just use the product and report when things look odd, especially when a new beta inadvertently stumbles over things that were working before.
The colrisation is just cosmetic and the human being is a perfectly adaptable entity. The AUTO-colorisation IS a very useful fetaure and is (or at least was) well over 95% reliable. I don't expect you to cater for every combination of quotes that may occur in the wild. I'm sure it could be done, but by then the routine will be so unwieldy not to mention slow to keep up with scrolling. I'll happily compromise here and there to avoid that.
As I said before, the issue of accuracy becomes much more important IF we go down the route of using the colours to drive the decision about which strings are found and/or changed.
If we go there, the current colorisation process' accuracy is most likely not good enough.
|
|
|
|
Post by George on Jan 17, 2023 11:34:54 GMT -5
I don't think the whole thing should be scrubbed, I believe it has merit. Sure the only real context classes we can realisticly see are comments and quoted strings.
BTW Robert, I do not like using the term STRING alone to mean a quoted string literal, I find it confusing. STRING by itself does not mean that. I see nothing wrong with continuing the use of the QUOTED term.
So if we only have 2 classes of context to support, why not just create new Kwds? Short is nice; Q and NQ work fine, but C and NC not so much. Maybe something longer, they won't be commonly used.
Advantage? No revisions needed to the color storage scheme, simply the addition of the Kwds and new code in the filtering part of the Search routine, which is organized so this is not disruptive to the main code.
These would be dependent on colorization support. I've been going through that code and yanked out all the recent kludges. The problem has basically been the state parsing loop had the comment testing done in the wrong order in relation to the others (quoted, etc). I've corrected that and things now look a lot better.
I'll put up a Beta and would appreciate it if you can spot any failures in the colorization scan. (ignoring multi-line comments)
George
|
|
