I'm using my phone so I'll reply in full tomorrow. I worked on this while I was in hospital and in physio, and it's very possible.
The text you see on the editor's screen gets there from a buffer. The buffer uses fixed length text lines, each 256 bytes long. So the code can find any cursor position by multiplying the Y coord by 256 (shift eight bits to the left). By increasing each line to 512 bytes, the second 256 bytes can hold the colour of each character. Simply offset 256 bytes from a character (eg.
256(An)) to get a character's colour.
The colour bytes can be written into the buffer during the Detokenise process. This takes a line of AMOS Basic Tokens and converts them back to text for display on the screen. When it processes each token, the token's type is obviously known and the appropriate colour byte(s) can be derived. The available types are:
| Keywords | AMOS Basic instructions, punctuation, math and logic symbols. |
| Names | The names the programmer has given to Variables, Labels and Procedures. It is not possible to split these up and use a different colour for each as Detokenise() doesn't 'know' the context until the program is Verified (the Test and Run process). |
| Numeric Literals | Any integer, single, double, hexadecimal and binary numbers in the code. |
| Text Literals | Any text enclosed in single or double quotes. |
| Comments | Any text following a Rem or '. |
A colour also needs to be defined for the inverted display of selected text (blocks).
When time comes to print to the screen, the function just needs to check if chroma-coding is switched on and use modified routines to do the work. This involves inserting appropriate 'escape' sequences into the text each time the colour bytes change value. So the output has to be buffered (using the general purpose
Buffer(A5)) then printed as a text string. This is much faster than doing it character by character to the screen. There are a few places where single characters are output to the screen (eg. as you type stuff in) which would default to the Keywords colour. The chroma-coding would occur as you move off the current line, in the same way that AMOS 'corrects' text case and spacing now when you move off a line.
I did a mockup of what it could look like a while back (program attached) that looks like this:
The stuff at the top of screen was just to see what standard palette colours look like. Modify the AMOS code to try different colours.
In addition, the text case for Keywords and Names is already implemented in AMOS Pro. The settings are in the editor config file (
DtkMaj1 and
DtkMaj2) but not currently editable. So they're fixed as mixed-case for Keywords and upper-case for Names. The options are mixed-case, upper-case or lower-case. So you could have Keywords in upper-case and Names in lower-case if they were made editable (see 'prrof of concept' below).
There's also seven longwords of free space available for 'future use' (thanks François!) so storing the chroma-coding settings is no problem - one byte each:
Ed_Chroma_Keyword
Ed_Chroma_Name
Ed_Chroma_Number
Ed_Chroma_String
Ed_Chroma_Remark
Ed_Chroma_BlockColour
Ed_Chroma_Flag
The flag is used to switch chroma-coding on and off as not everyone likes to use it.
I did a 'proof of concept' for the DBL code needed to write a dialogue to edit all this (file also attached - excuse the messy, this was just to see if it was feasible - it is
). It looks like this:
And with a dropdown for the colour selection:
The layout and design leave a lot to be desired, but this was just to prove it's possible. It's one thing to work out how to implement chroma-coding and another thing altogether to enable the user to set it up! I would move the dropdown buttons to the right of each colour and drop the dialogue down there rather than over the colours as in the above. Also, there's no labels for the text case three-state buttons (I just wanted to see if three-state was possible). I envisaged a sample window on the right to display what the result looks like - would have to be a machine code program to get the necessary speed. Anyway, these are just musings.
I've attached the AMOS progs that produced the above screens. You'll also need the attached AMOSPro_Default_Resource.Abk file to replace the original in the APSystem directory of your AMOS installation. It contains the images for the multi-state buttons and some revised DBL code for the file selector.
The Select Case you speculate on is just not feasible without major code changes. It's a structural instruction (like
Do ... Loop and
If ... Then ... End If) that needs offsets inserted during Test and Run and would require major changes to the Verify() code. Any changes that affect program structure are almost impossible
.
Now, back to the bugs as this is all enhancement and not fixes! And now I'm recovering and more active, I want to get stuff out there instead of just talking about it.
Author
Topic: AMOS Pro 2: New feature suggestions List (Read 17634 times)