|
|
Post by Stefan on Dec 21, 2020 13:35:23 GMT -5
Hi George,
I'm asking because the .AUTO files actually implement TWO functions. Coloring is one, 'AUTOCAPSing' (especially in combination with CAPS ON) is the other.
As it stands, OPTIONS SCHEME offers a 14-colour palette, plus, what used to be called NORMLO and NORMHI.
I wonder if it would be possible to allocate a Scheme 'identifier' to NORMLO as well, which could be coded in the relevant .AUTO file to refer to the NORMLO colour.
This would be useful to AUTOCAPS a word independently, i.e. without assigning it a specific colour.
Presently, we can only AUTOCAPS a word that is in NORMLO colour, by sacrificing/duplicating a palette entry for it.
I imaging that internally, it doesn't need to be a 'real' number/letter. The chosen character just needs to be accepted as valid when the .AUTO file is loaded, and... ...the AUTO logic would need to recognise it as a signal to bypass the colouring logic and still do the AUTOCAPS part.
(Fingers crossed you didn't store it as a 4-bit value)
|
|
|
|
Post by George on Dec 21, 2020 16:17:11 GMT -5
Stefan: The color handling is a very messy area. Frankly, the ROI in changing the AUTO syntax, and all the percolated changes is just not worth it. Yes, giving up one Scheme out of 14 may be a restriction and logically annoying, but it doesn't seem too onerous a burden, after all, it still leaves 13 schemes. I think that's more than enough for any colorize scheme. (This from the point of view of someone who's partially color blind).
George
|
|
|
|
Post by George on Dec 21, 2020 16:50:31 GMT -5
Robert: No, it's a 5 bit number.
George
===> Sorry for my bad, but in my fuzzy memory when you did this, I thought the reason you had 16 values, 2 of which were reserved for the regular hi/lo intensity, was because you couldn't store more than 16, because the value was crammed into some larger thing. So if that isn't it, did you limit to 16 because adding more would make the GUI more complicated? |
|
|
|
Post by Stefan on Dec 21, 2020 18:00:52 GMT -5
LOL... 5-bits gives you plenty of room then 
Seriously - I never use dark blue. So I pinched that one for another NORMLO.
T'was a long shot anyway and I figured you'd have bigger fish to fry. No worries. Thanks for looking.
|
|
|
|
Post by George on Dec 22, 2020 11:22:06 GMT -5
Robert: The 5 bits are not just for Schemes, but for other Standard colors. Line#Hi/Lo, Tab-Label Mod/Non-Mod/Active/Inactive, PFK Help lines, Status line, etc. etc. Elsewhere there are 4 bits for Hi-Lite colors. These are all packed, along with some other attribute flags into a single Attribute field.
The reason it gets weird is that some of these are re-DIM'ed as a table which overlays a fixed series of global color variables. There there is a bunch (45-50) of equates that have to match carefully with all that data.
George
|
|
|
|
Post by mueh on Dec 23, 2020 4:46:11 GMT -5
George: I was thinking to use the predefined HILite colors in AUTO Files in addition to the Scheme colors .
Maybe the following 1 line change marked with MUEH is stupid but schouldn't we give it a try .
Mary Christmas ! Will not bother you the next days .
_ObjENV.inc
me.InitOKW("Scheme32FG", 1, VARPTR(Scheme(32, 1)), "&HFFFFFF") ' SCBlue
me.InitOKW("Scheme33FG", 1, VARPTR(Scheme(33, 1)), "&HFFFFFF") ' SCGreen
me.InitOKW("Scheme34FG", 1, VARPTR(Scheme(34, 1)), "&H000000") ' SCYellow
me.InitOKW("Scheme35FG", 1, VARPTR(Scheme(35, 1)), "&HFFFFFF") ' SCRed
me.InitOKW("Scheme36FG", 1, VARPTR(Scheme(36, 1)), "&HFFFFFF") ' SCBlack
me.InitOKW("Scheme37FG", 1, VARPTR(Scheme(37, 1)), "&HFFFFFF") ' SCNavy
me.InitOKW("Scheme38FG", 1, VARPTR(Scheme(38, 1)), "&HFFFFFF") ' SCTeal
me.InitOKW("Scheme39FG", 1, VARPTR(Scheme(39, 1)), "&HFFFFFF") ' SCViolet
me.InitOKW("Scheme40FG", 1, VARPTR(Scheme(40, 1)), "&H000000") ' SCOrange
me.InitOKW("Scheme41FG", 1, VARPTR(Scheme(41, 1)), "&H000000") ' SCGray
me.InitOKW("Scheme42FG", 1, VARPTR(Scheme(42, 1)), "&H000000") ' SCLime
me.InitOKW("Scheme43FG", 1, VARPTR(Scheme(43, 1)), "&H000000") ' SCCyan
me.InitOKW("Scheme44FG", 1, VARPTR(Scheme(44, 1)), "&H000000") ' SCPink
me.InitOKW("Scheme45FG", 1, VARPTR(Scheme(45, 1)), "&HFFFFFF") ' SCMagenta
me.InitOKW("Scheme46FG", 1, VARPTR(Scheme(46, 1)), "&H000000") ' SCWhite
_TabData.inc
METHOD ClrLoad() AS LONG
ValidateScheme:
lclScheme = VAL(parsed(1)) ' Get the scheme number
IF lclScheme > 31 and lclScheme < 47 THEN RETURN ' MUEH allow HILite Color
IF lclScheme < 1 OR lclScheme > 14 THEN GOSUB KillClr ' Invalid scheme number kill it
lclScheme += 1 ' Adjust scheme up past TxtLo and TxtHi
RETURN '
|
|
|
|
Post by George on Dec 23, 2020 10:22:09 GMT -5
MUEH: Minor problem, it skips the lclScheme += 1 adjustment. Second, the bigger number range still won't fit. There is still no room in the attribute field to handle the extra number range.
George
|
|
|
|
Post by George on Dec 23, 2020 11:51:58 GMT -5
My thought, after setting up many AUTO files is simply "What the heck can the need be for so many colors? And why would different Profiles want different schemes?
A literal is a literal - color it some way.
Delimiters are delimiters, pick another color.
etc.
Why would a literal in REX need to be colored differently from a literal in Basic, or JCL or COBOL etc.
Any revision to color handling would be very disruptive.
George
|
|
|
|
Post by George on Dec 23, 2020 15:14:11 GMT -5
I totally agree. Remember before the last color re-write, AUTO supported (I think) 31 colors. This after some user asked for an expansion over the previous (also I think) 9.
He sent me a sample of his 'desired' AUTO file and he had somehow managed to create some logical usage for all those colors. It just baffled me. (But then I don't distinguish colors well)
George
|
|
|
|
Post by nicc on Dec 23, 2020 16:50:14 GMT -5
I code almost exclusively in Rexx. I code keywords in red, BIFs in cyan/blue, numbers in yellow, strings (single or multi-character) in white and comments in gray (to send them into the background). Everything else is green and a black background. Panels are having colour added to them now that Windows 10 console session handles 'ANSI' codes as DOS used to do.
|
|
|
|
Post by Jo on Dec 25, 2020 10:20:53 GMT -5
I extensively use auto-colorization for all of my filetypes, currently 9 colors for ooREXX, 9 for DosBAT, 11 for AVR-Assembler, 7 for MACRO, 4 for AUTO, 4 for .INI and .INF-files and I have C and QtScript and .BAS-files in color. Keywords are not just keywords, some are preprocessor- some macro- some procedure- specific, therefore I use a slighly different color or background.
It was a hard job some years ago, when I had to condense all different Color-SCHEMEs from the old AUTO-files to the new "OPTIONS SCHEMES", but it's done now. OK, I lost some color-definition which were only used by a single filetype. So, yes, I use almost all 14 available colors.
Jo
|
|
|
|
Post by Stefan on Jan 1, 2021 19:01:06 GMT -5
I'm like Jo. I use a lot of colours.
But I also stick to some common practices for a common look and feel. So having the scheme based only on profiles would be tedious as I'd lose the common look and feel unless I duplicate the colour info in each profile.
With a bit or discipline on my part, I even have a sensible solution for multi-line comments in REXX files. I also use COMMENTn entries for some special cases. For instance, in some BAT files I use a COMMENTn % % definition to pick out variables and in INI files, I highlight the section headers with a COMMENTn [ ] entry.
I use the same colours everywhere regardless of language/filetype for language keywords, whole line comments, part-line comments, numerics, quoted literals, special characters. I highlight Keyword groups in a brighter colour so that sequences like IF-THEN-ELSE-ENDIF, DO-WEND, WITH...END WITH, etc 'pop' out, especially useful for Macros where the interpreter is poor at spotting mismatches.
One niggle I do wish we would fix is the confusion that arises when a single quote and a comment definition occur on the same line.
|
|
|
|
Post by George on Jan 2, 2021 13:16:45 GMT -5
Just for reference, all the COMMENTS are looked for BEFORE things like Kwds, quoted strings, numbers etc. are scanned for.
I too would like to know more about the 'confusion' with single quotes.
George
|
|
|
|
Post by Stefan on Jan 5, 2021 12:58:27 GMT -5
Hi Guys...
This stuff was produced using version v2.3.20365
Here's some - admittedly contrived - data that demonstrates some peculiarities of the AUTO highlighting. To ensure you see what I see. I attach a ZIP file which contains: - SPFLite.CFG - Switch to my config file to match my colour scheme and eliminate other factors during testing/diagnosis.
- DATA.STEF - the data used to demonstrate the effects - STEF.AUTO - A colorisation file for the STEF profile. - AUTO.AUTO - Colorisation for the AUTO files (optional, but I use it to show scheme numbers in their corresponding colour in AUTO files.)
Assuming you... (1) temporarily switched to my CFG file and ![]() (2) placed the xxxx.AUTO files in SPFLite's AUTO folder (3) Load STEF.AUTO into an editor tab for easy access to the definitions ...you should see this when you load STEF.DATA into another editor tab
Let's briefly look at STEF.AUTO first.
- All the special characters relevant to this discussion are mapped to Scheme 10 and are also listed as DELIMS. - COMMENT2, COMMENT3 and COMMENT4 are used in the conventional way to highlight an entire line when the start-comment character appears in column 1 - COMMENT1 defines anything between < and > as a comment, anywhere on the line. Used here to hi-lite clues to the real data
Now to STEF.DATA.
Line 3: The ']' in col 22 and the '{' in col 26 are not displayed in Scheme 10 colour. Perhaps SPFLite assumes a comment to be the last thing on a line.
That theory is strengthened by replacing the '<' in col 12 with another char or blank. Without that 'start-comment' marker, the rest looks as expected.
Not unreasonable, given I'm misappropriating a COMMENT construct for another purpose.
However, put the '<' back in 12 and slowly insert blanks after the ']' char. When the '{' char moves to col 39 suddenly all is well. The ']' in col 22 and the '{' in col 39 are both coloured correctly. Line 4: Exhibits the same behaviour, but here all is well from col 38 onwards, wjhich makes me think the columns may depend on where the '<...>' string ends.
Line 3: Insert more blanks, shifting the '{' further right. For cols 39-43 all remains well. Col 44 doesn't work, neither do cols 48-49 and any col after 53.
Delete the inserted blanks to put the '{' back in column 39. Then, starting in col 23 (after the ']'), over-type the blanks with a non-blank char, one at a time.
This time the ']' hi-lite goes 'out' for any non-blank chars in cols 23-27 inclusive.
A non-blank in cols 28 and 29 is ok, but a non-blank in cols 30-38 leave the ']' unaffected but the '{' in col 39 goes out.
Lastly, and THE MOST RANDOM aspect of all given that colorisation works on one line at a time, ...
While working through the above scenarios, I noticed that occasionally(!), but usually following a RELOAD, some lines of the file suddenly show strange colorisation effects. See the picture below, where part of Line 4 appears in the QUOTED colour despite there being no quote characters on that line, or indeed anywhere in the data file. This effect is not readily repeatable, but it clearly can happen.
|
|
|
|
Post by Stefan on Jan 5, 2021 13:53:58 GMT -5
Apologies George, I just realised I didn't answer your specific question about single quotes.
You already have a copy of my AUTO.AUTO and SPFLite.CFG files from the previous post.
Using that setup, all text in a .AUTO file following a semicolon should be in grey/dark-white.
This is the start of my MACRO.AUTO file
000001 ; SPFLite Colorize file for thinBasic Macros
000002 ;
000003 ; Note: Highlighting (1) used for 'Debug' functions to allow easy
000004 ; removal of these statements after testing is complete.
000005 ;
000006 ; Note: Highlighting (10) used for statement pairs (e.g. FOR...NEXT, etc)
000007 ; to aid detection of orphaned singles in the pair.
000008 ;
000009 QUOTED 7 ; Quoted strings
000010 NUMERIC 7 ; Numeric Literals
000011 ;
000012 COMMENT1 1 '# 0 ; Used as debugging comment/hi-light
000013 COMMENT2 4 ' 0 ; Elevated comment (anywhere)
000014 COMMENT3 11 /* */ ; Inline comment
000015 COMMENT4 11 REM 0 ; Whole Line comment (alternative)
000016 ;
000017 DELIMS ~!@%^&*()-+=|\/{}[]:<>,.?;
Part 1:
If you load this into the editor as an .AUTO file using my CFG and AUTO.AUTO, you'll see that the comment at the end of lines 12 and 13 are not grey. Confusion stems from the use of a single quote as a comment character for thinbasic macros. It seems QUOTED doesn't support there being no closing quote on the same line.
Trial and error suggests that the COMMENTn entries are processed in the order they are named, e.g. COMMENT1 precedes COMMENT2 etc, not in the order they appear in the .AUTO file.
Part 2: If you have a thinbasic line like
000010 DIM AS NUMBER topPtr, curPtr VALUE 0 /* some comment */ '# DEBUG - remove later
The '# DEBUG... part should appear in Scheme 1 (Pink).
Whether it does nor not, depends entirely on how many blanks there are between the */ marker closing the preceding comment and the '# sequence. You can test this by inserting extra blanks, shifting the '# sequence to the right and watching the colour change.
|
|
