6502.org

If it's any comfort, I feel it's correct to "necro" an old thread on the same topic rather than start a new one; why toss aside all the experience that's been built up in the old thread, especially one with as many good points as this one?
I have to say, I like several of your choices of what elements you've chosen to distinguish from others; it seems to help make the important things jump out a bit more. (I'm not a big fan of colourising things, but I do often find that using around three different ways of marking syntax can be helpful without being intrusive or annoying.) The one major thing that's missing in your example, though, is what labels look like when used as instruction operands.

That said, what is the point of different colours for label definitions, instructions, and operands in general? It seems to me that the separate columns already do a good job of distinguishing them.

I mention this because the more colours you use, the less power you have with contrast. While BDD's colour-blindness may not be the common case, you should note that the presbyopya that commonly comes along with ageing eyes is not just about focus but also about brightness and contrast. More light reflected from the subject (or generated from it, in the case of computer screens) contracts the pupil, thus improving focus. Thus, light backgrounds with dark text tend to be easier to read, and things like dark red or dark blue on black, being both dark and low-contrast, are seriously suboptimal.

As others have pointed out in this thread, often better syntax or better use of existing syntax is a better solution to readability problems than colourisation. My attitude is that if something is hard to read without colourisation, look first at the syntax, rather than using colourisation as a crutch for bad syntax. Often better formatting or a macro will do a much better job of fixing the problem.
This is where, again, stepping back and looking at readability as the problem, rather than lack of colour, can help. Monochrome terminals do have distinguishing modes even without colour; the old IBM MDA offered both bright text and underlined text, and these days you can also usually get italics in a monochrome terminal display. Just two or three distinguishing modes can usually do 80% of the work that eight modes would do. And using fewer modes allows for more contrast (in the generic sense) between them, which is good for a wide range of issues, including presbyopia and colour blindness.

I hate to bring up terms like "abilism," but while BDD may have more difficulty with contrast for some particular colours than many of us, my very-normal-for-a-50-year-old vision (according to my optometrist) also finds the low-contrast medium-blue-on-black to be a lot less visible than even grey on black, in a way it wasn't twenty years ago. (And don't even get me started on dark blue on black.)

BDD's vision "problems" are ones that everybody has to some lesser degree, and for most people those "problems" will continue to get worse as they age.

This is a post about regular expressions specifically to color (aka highlight) syntax, and I provided the regular expressions I am currently using as well as an example of them in action. I found this post because I was specifically looking for an already arrived at solution but didn't find one so I thought I'd give back to this wonderful and informative community. I also attempted to head off the last 12 posts at the pass by acknowledging you may hate the colors etc. I chose (how prescient of me.) If you don't like your syntax highlighted you are free to use your current set of tools. I will make a separate post when/if my IDE is ever more publicly available and at that point you can trash it to your heart's content

Well, that's what the first post was about. As the impliciations of any particular thing arise, they often get discussed too, and that's usually not a bad thing. I think it's generally good to be informed that, e.g., dark blue on black is difficult to read for many, even if you decide to use that for your own personal editing.
Well, let's not exaggerate; were you really trying to head off the four posts before yours as well?

Anyway, amongst all the discussion of blue-on-black text there are still some questions there that some of us might like to see answers to. Such as, how do you colour symbol references (as opposed to definitions)?

This is a good question but seems highly dependent on coding style. For me, I'm not actually sure I want to color labels (or subroutine labels) but I think I do want to color constants. My style is ALL_CAPS_SNAKE_CASE for constants so this seems somewhat doable, though if you uppercase your instructions then your parser needs to give precedence to that rule.
My regex system is pretty primitive so despite the vigorous discussion, it's fairly understated what I'm trying to accomplish.

(also, the specific colors for all of these in my IDE is configurable, including making it monochrome)

Err...so currently you colour them white? Maybe it's easier if you just post another image that includes some labels of various kinds in the operand field, so we can just directly see what it does. (After you've finished tweaking that aspect of it, of course, if that's not yet done.)

I hadn't thought of looking at label style and colouring labels differently based on programmer conventions. That's actually quite an interesting idea.
Yes, I am detecting some tendency to understatement there, and I like that; the point of syntax highlighting is to make things more readable, after all, not make your editor look like a cool demoscene program ever. Allowing configuration of the colours in your IDE will probably make it perfect for everyone, letting them dial up or down the amount of colour to taste.

One thing you might consider if you're writing your own editor/IDE, BTW, is using a proper parser rather than trying to hack highlighting with regexes. (Ideally, you'd have pluggable parsers to suit different assemblers, if you support more than one.) Once you learn a bit about them, real parsers are not that hard to write, especially if you take advantage of the parser generation tools offered by many languages. (E.g., for Java there's ANTLR which is incredibly powerful and has one or two really good books to get you up to speed.)

Not only do they make identifying syntax far easier and more reliable than mucking about with regexes, but they also let you add more fun IDE features such as popping up definitions of symbols, highlighting undefined symbols, refactoring, and so on and so forth.

For me, one of the great failures of Vim is that it uses regexes for syntax colouring, which gets seriously painful. (I remain a die-hard Vim user, however; nothing can compare for speed and range of cursor movement commands.)

Hi!
I strongly agree with this, and I suggest a PEG grammar, as it is fast and very easy to write. Have you tried the "Vis" editor? https://github.com/martanne/vis#vis---c ... xpressions

It uses a PEG parser for syntax coloring, and it is smaller and faster than Vim.

Have Fun!

Especially if you're not using a parser generator tool, I concur. PEG parsers are easy to write by hand, and very efficient. It also can avoid a separate lexical analysis stage. I even use PEG parsers in 8-bit assembly code!

In my research I also noticed below that vile has a particularly nice, easy and clean way of dealing with recognition for higlighting: it runs an external program on the file which returns markup that the editor then uses to highlight the code. For an IDE this markup could also include syntatic information, lists of symbols, call information/documentation and so on that would provide the information needed for context-sensitive completion and the like.
I'd never heard of it, but it's certainly interesting. Looking into it sent me down a deep rabbit-hole of research, including structural regular expressions, that used up several hours of my day. :-/ Unfortunately, while it looks like a good editor, a few issues specific to the environments I use still make Vim a better choice for me. (Roughly: Vim is a hot mess roasting on a dumpster fire, but it's featureful and everywhere.) But thanks for the reference!

Hi!
Well, FastBasic uses a "simplified" PEG parser, this is expressed as a parsing bytecode that the 6502 code interprets to parse the language - this makes the parser very small, and the speed is "fast enough" for a parser that compiles the code in one pass.

One of the advantages of this is that almost all spaces are optional, and combined with abbreviated statements you can write very condensed and imposible to understand code - good for ten-liner contests!. See for example this 10 liner game by Vitoco: https://www.vitoco.cl/atari/10liner/WAZERS/ Sorry???

Well, I use vim as my main programming editor, for the same reasons, but I use vis as a small editor that I can install everywhere, as it is much smaller and faster.

Have Fun!

(I do apologise for my outburst: I support efforts to improve accessibility, and personally I too struggle with blue on black. A polite request to post a higher contrast image would often be appreciated by others, as well as the requester. I was having too bad a day for any polite requests, unfortunately for all of us.)

I'm actually using "vim" on Linux. Highlights 6502 assembler just fine

(edit: sorry for being late to the thread...)

Wow, who on earth defined these default colors for vis (on kubuntu 20.04)