Basically, this algorithm tokenizes the source code, and tries to color each token so that identical tokens have the same color, but similar-looking tokens have very different colors. When tokenizing it specially handles comments and quoted text.
That's an interesting approach to countering errors from "it's almost the same but I didn't notice they were different". I wonder - if I were trying to review source code that were malicious, maybe I could vary the color algorithm using a random source so that the source code writer couldn't make different tokens look similar in color. That might be an interesting countermeasure to some kinds of underhanded code.
Probably not helpful to you, but maybe some other lurker.
I'm not involved in any way, I just ran it for a while at one point.
radare2 is a portable reversing framework. I can't think of 2 projects more dissimilar. Perhaps you were thinking that the highlighter actually did something other than color text in an arbitrary way? Can you give an example of something that you would expect to change about it, especially at the rate of multiple times a day?
You don’t need a package for this, Sublime Text 3 already does this automatically .
The simplest way seems to be to use the "Celeste" color scheme which implements this. Is this the only way? I'd like to use a dark theme, like the default Monokai.
For dark mode, I use this project — https://github.com/cixtor/monnokay
I haven't used the plugin since the ST2 days, so I didn't realize it was no longer needed.
- preference: semantic highlighting
Yes, that's called a programming language :^)
Assembly is usually essentially a macro engine over the actual instructions you are emitting for your processor, and the Intel x86 chip manuals or whatever you're targeting use the outrageously long proper names, so your assembly will too. Heck, the author mentions specifically reading assembly too, so knowing what you're reading is 1:1 with the actual instruction stream is helpful, no matter how bad the official names are.
Actual programming languages just abstract away some complex instructions like SSE vectorizing (which have famously terrible names) to some high-level API and intrinsic functions. And you should too.
I don't see why that has to be the case; why I'd must use Intel specified mnemonics instead of my own syntax? While not as radical, the att vs intel syntax demonstrates that the vendor syntax is not the only option. As long as the syntax captures all the details of instructions to be completely unambiguous then it should be perfectly interchangeable.
I specifically do not desire higher level of abstraction because I want to maintain that 1:1 relation with the actual machine code. Heck, even Intel mnemonics do not truly have 1:1 relation to machine code, because the instruction (encoding) can depend on operand types.
Edit: Here's a scope based js highlighting repo that cites Crockford as the inspiration but unfortunately he posted the linked description on Google+ so... uh... oops
I'm not sure about both because, i) there are only a handful number of mutually distinguishable colors ( does mention the same complication), ii) we often want to highlight both the similarity and difference among identifiers and the cutoff is not clear. For i) we may want to leverage more formattings; for ii) I really don't have a good solution.
How difficult would it be to implement this as a VSCode extension?
I do wish it did some syntax highlighting, but one could easily imagine blending between this and conventional syntax highlighting.
It's a little weird to me because unlicensed code is very different than the Unlicense license.
It's fine that mov doesn't look like eax, but I'd rather prefer pmulhw and pmulhuw to be shown as differently as possible.
I'll have to remember to load up CSS or a test suite (with lots of framework calls) using this approach.
Brings back memories.
Only the next day after the deadline pressure was gone did I spot the problem.
Some safety critical areas of software are done this way, in aerospace for example. But run-of-the-mill automation jobs aren't.
actually, I encourage anyone in coding to share run-of-the-mill maintenance of outdated industrial automation, as a gig. I'd read that blog.
I think it would be the single best thing to help a huge amount of people.
Or at least make it easy to turn the rainbows on and off.
Does anyone else find this terrifying? Nuclear power plant automation should be done in the safest of the safe languages. I would be alarmed at the thought of stuff like this being written in C, never mind in assembly!
It would be weird to care about memory safety when your board doesn't even have a heap!