|
Post by Stefan on Jan 9, 2023 10:15:36 GMT -5
George,
This is weird but I'll try to describe it. I've not seen this on any version other than 23007.
On several occasions, when typing in text, I notice that some characters, apparently 'randomy' change CASE as I type. It's as if I had typed a keyword which is subject to either AUTOCAPS or AUTOCASE.
It affects random and isolated lines (I've not been able to ascertain how these are determined) and usually only affects some columns within the affected line. It does not matter what data was in those columns before, they can have had characters in them or have been blank.
The text being typed is not a keyword in the AUTO file.
In fact, the capitalisation can occur in mid word and affect only a few chars, sometimes consecutive, sometimes spread out.
It doesn't matter what the characters are. You might type 'BlockRow' and get 'bLocKrow'
Replace that with 'aaaaaaaa' and get 'aAaaAaaa' Note that the colunm affects the change in case. Type the same thing again on the same line but in different columns and it might be fine or it might exhibit some other capitalisation effect. Also affects data wihich is entered via a KEYMAP. I have a key set to (SaveCursor)(NewLine)(BackTab)[--# DEBUG ](RestoreCursor)
to place the --# DEBUG comment at the last tab stop of the current line.
The result might read as --# DEBUG or it might be --# debuG , etc
As I said - WEIRD!
UPDATE 1:
I note that the phenomenon is more likely to appear AFTER I have used the INSERT and/or DELETE keys which shift data around. In my case INSERT is mapped to the (DataInsert) primitive and DELETE is mapped to the (DataDelete) primitive. The keys' SHIFT behaviour is mapped to (Insert) and (DFelete) respectively.
I also note that when a column insists that its value must be upper case, a SAVE followed by RELOAD allows me to overtype the capitalised string with the correct text. \UPDATE
UPDATE 2: This may be more helpful as hints go.... I just noticed that a F p'>>>' command finds string 'Rename' and reports "Chars REN found".
This is when I realised that the word "RENAME" is stored in the file in UPPER case, but AUTO processing 'displays' it as "Rename" because there is an AUTOCASE 5 Rename statement in the relevant AUTO file. So the find command is latching on to what is actually there, not what is being displayed.
\UPDATE 2
|
|
|
Post by George on Jan 10, 2023 9:35:07 GMT -5
Stefan: So when you SAVE a problem file, the saved file has the mixed case characters? i.e. it's not just a display problem, the actual data is mixed case.
Truly weird, so far I can't trigger it.
George
|
|
|
Post by George on Jan 10, 2023 9:43:50 GMT -5
Stefan: I had a look at the recent change to handling the altering of SCHEME attributes, that was in 23007. Found another ATTR function that I missed. Try this temp version, where that has been corrected. George SPFLite2.2.7.23010.exe (514.5 KB)
|
|
|
Post by Stefan on Jan 10, 2023 12:24:48 GMT -5
George, Sorry, I've been thinking some more about the FIND P'>>>' aspect and concluded that it's a red herring. I was being stupid!
Answer to your initial question: Yes, the file in question contains mixed case text. In this instance, the program that created it, wrote the word RENAME in upper case. When SPFlite loads it and applies the AUTO colorisation, the word " RENAME" appears(!) as " Rename" because of a " AUTOCASE <color> Rename" stmt.
I previously failed to appreciate that, AT THIS POINT, this only affects the display, so the word is still 'RENAME' in the file being edited. And it will remain so, unless the file is SAVEd and the AUTOCAPS ON profile setting does it's thing. This explains why FIND P'>>>' finds the "REN" string and a FIND C'Rename' finds nothing. SAVE and RELOAD the file and all works as expected!
Regarding the odd column capitalisation I've installed v23010. Now, if only I could remember how to provoke the issue...... I'll let you know.
|
|
|
Post by Stefan on Jan 10, 2023 18:03:56 GMT -5
George,
Bad news:
Version 23010 is still afflicted by the "odd column capitalisation" issue.
Good news: Version 22217 was not afflicted
See if you can reproduce this yourself using this simple test. I attach my MACRO.AUTO file and some test data containing a few lines from an EDIT MACRO. The code is unimportant. Focus on how the "keywords" are capitalised.
I deliberately doubled up each line in TEST.MACRO. to show the effect.
Simply overtype all of the second line in each pair with a string of a lower case letter - I used 'p' but 'e' works well too. You should see something like this:
Note the strong, if not perfect correlation in the capitalisation, almost exactly where AUTO-colorisation had capitalised the previous text.
This doesn't explain why I previously saw this kind of display anomaly on what were 'empty'/blank sections of lines, but I cannot seem to reproduce that reliably. I hope the above effect is the same for you as it is for me and gives you a clue of where to look in the code.
|
|
|
Post by George on Jan 11, 2023 9:30:15 GMT -5
Stefan: OK, I'm getting it, really, really weird. Should be interesting.
George
|
|
|
Post by George on Jan 11, 2023 10:12:21 GMT -5
Stefan: This is one of those simply unbelievable ones.
It SHOULD be failing in the production version, but doesn't. Now the Beta versions have had some changes in the Attr handling code, but I'm damned if I can see how those changes would affect this. But .... obviously they did and exposed this very old bad code.
Basically simple, the routine that performs the colorization scan works with two strings. One the actual text, and the other string that holds the matching attribute bits.
At the start it carefully makes sure the attribute string is = in length to the text string, adjusting it if necessary.
Even though it completely rebuilds the contents of the attribute string, IT DIDN'T RESET the previous content. So any 'normal' characters just inherited the previous attribute, instead of being set to normal default scheme.
I'll post a fixed Beta so you can test if it's now OK.
George
|
|
|
Post by Stefan on Jan 12, 2023 7:25:21 GMT -5
George,
I'm running v23011 now. First impressions are positive. I'll let you know more in a day or so.
|
|
|
Post by mueh on Jan 13, 2023 5:00:47 GMT -5
George: There is following Problem with 23011 (okay in 22344) Color test.macro ( i use no auto file ) with cmd FIND R'\".+\"' ALL +red overtype IF in line 7 and the color vanishes .
|
|
|
Post by mueh on Jan 14, 2023 2:58:50 GMT -5
George: Installed 23013 but problem remains which occured first after 23011 . It occures only if no AUTO file exists or HILITE AUTO OFF in profile . The color set by find should not be set to blank when line txt is modified . (checked it with Get_Clr_Line$) See previous page for screen shot . Thanks
|
|
|
Post by George on Jan 14, 2023 10:45:55 GMT -5
MUEH: Fails here on my test version too. Well I'll be da*ned. It's like I did nothing!
Going back in.
George
[UPDATE]
Can't explain it, I tested this, yet the code is the exact REVERSE of what's needed. Guess I'm losing it.
New Beta coming.
[/UPDATE]
|
|
|
Post by Stefan on Jan 14, 2023 17:29:26 GMT -5
George,
Betas v23013 and v23014 introduced a new twist.
It affects BASIC macros and the tricky field of duplicate use of the single quote in SPFlite macros. Basically, the change(s) broke the comment recognition. I guess it doesn't affect 'normal' Basic because that only recognises double quotes as literal strings. Hence it probably isn't worth changing the code. Just compel/advise users to stick to strict BASIC rules and use only double quotes for quoted strings. WITHIN a double-quoted literal, use of single quotes and 'reverse' single quote is fine. To ensure this is recognised correctly, the QUOTED statement in MACRO.AUTO must be explicit, excluding the single quote, e.g. QUOTED <colour> " " ` `
('Text literals shown in blue-bold, comments in Red-italic, the underlined text is considered to be neither comment nor literal and thus colorised according to WORD/AUTOCASE, etc)
Prior to these versions, the following code snippets were correctly recognised and colorised: NEXT ' w ' Only wrap-around ONCE '--------------------------------------------------------------------------------------- ' SHOW or EXCLUDE the procedure body according to user's specification, UNLESS... ' we're just finding the nearest (PREV or NEXT) routine header to the current line '---------------------------------------------------------------------------------------
In v23013 and 23014 I see this instead: NEXT ' w ' Only wrap-around ONCE
'--------------------------------------------------------------------------------------- ' SHOW or EXCLUDE the procedure body according to user's specification, UNLESS... ' we're just finding the nearest (PREV or NEXT) routine header to the current line '---------------------------------------------------------------------------------------
|
|
|
Post by Robert on Jan 14, 2023 19:30:50 GMT -5
This logic is contained in a function called ClrLoad, which I extensively rewrote some time back. However, when I was done, the errors you cite above were not present. The most likely cause of this is that somehow strings are being found first.
There is some (relatively) new logic in this code which adds default quotes of " and ' unless you explicitly ask for your own quote types. For Basic, the QUOTED directive in the AUTO file gives the Scheme Number and then optional quote delimiters, which BAS must specify as " only. That should be enough to prevent ' from being used as a string. In addition, if there is any overlap between comments and strings, an error is reported. So you can't use ' as a comment and as a quote too, it rejects that.
The validation code in ClrLoad *already* "compels" users to define these delimiters correctly.
|
|
|
Post by Stefan on Jan 15, 2023 11:03:11 GMT -5
Agree with all of that, except the part about the error message.
Doc says...
If entered as simply QUOTED sn (with no optional parameters) then literal quoted strings are assumed to be delimited by the default set of - Single quotes '', Double quotes "" or Back Quotes ``
It doesn't matter if one accepts the 'default' as described above or explicitly specifies the 'quote' character pairs, there is no error message message. eg: some lines from my MACRO.AUTO file...
; SPFLite Colorize file for thinBasic Macros ; ; Notes: ; 1 (PINK) used for 'Debug' functions to allow easy removal of such ; statements after testing is complete. ; Also for | and & to avoid AND/OR confusion with REXX ; ; 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 7 ; NUMERIC Literals ; ; Clr Trig Loc ; --- ---- --- COMMENT1 1 '# 0 ; DEBUG line hi-lite (PINK) COMMENT2 4 ' 1 ; Standard comment (RED) - whole line
Extra:
Leaving the quote situatuon for a moment, I also note that the following "Comments" used to be colored correctly but now are not. Here are the first few lines from my AUTO.AUTO file.
; SPFLite Colorize file for AUTO ; Uses Standard LO colour to effect the AUTOCAPS only without colour change ; ; Clr Trig Loc ; --- ---- --- COMMENT1 11 ;; 1 ; Commented out as duplicate (AUTOCLEAN) COMMENT2 7 ; 1 ; Section Header COMMENT3 11 ; 0 ; Inline Comment
None of the text following any of the semi-colons are recognized as a comment any more. All is treated as 'normal text'
|
|
|
Post by George on Jan 15, 2023 14:16:12 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
|
|