Syntax highlighting for dis module

Syntax highlighting is good addition to improve readability, and the way of giving a context to special parts of output text. Adding it to dis module can be considered as developer experience enhancement.

I have minimal “proof of work” implementation (I see issues with spacing, for now – difference in outputs when NO_COLOR is set, but anyways):

Highlighting can also be more context specific. For instance, different color for unary, binary/in-place … opcodes (= in the way opcodes groupped in documentation of dis module).

Highlighting does not introduce any breaking changes, it can be disabled too – if user does not want where it implicitly follows NO_COLOR standard, which is implemented in ThemeSection.no_colors (and here).

I haven’t seen where this idea was proposed/discussed (in forum, github). I would like to hear your opinions. Any ideas & criticisms are appreciated.

And, I’m ready to work on this.

Thanks.

17 Likes

Yes, this could good. Another idea may be to use the same colour for LOAD_*, and another colour for POP_* and another for RETURN_*, and so on. It’ll be good to get input from people who use dis more often than me.

2 Likes

I’d love to see it!

If I had a magic wand, I’d only colorize labels and jumps instructions, because that shows me program flow at a glance. So all the .L123, …JUMP…, and …CALL….

Though I’m sure there are heavier users of the dis module than me and they might have different opinions.

4 Likes

Looks cool! Another possibility: Would be nice to be able the stack-effecting operaitons - loads and pops. I mostly use dis.dis() to explain to people what actually happens in code, and to compare optimizations.

1 Like

You mean highlighting only stack affecting opcodes (=loads/pops) ?

Re-posting current state (from PR)

1 Like

Not ONLY highlighting those, but giving a clear colour to them, and different colours (ideally counterparts in some way) so they can be easily eyeballed.

1 Like

Adding color to the dis output is a great idea. I’d just caution to not make too colorful. That could instead make it even more difficult to parse.

Comparing both screenshots, the initial and the last one, I honestly would prefer the first from a readability standpoint. Just because the colors don’t get in the way.

7 Likes

Looks good. Make sure it’s tested / configurable for light backgrounds as well.

The contrast on the names and constants in grey is bad. Better to use fewer colours and limit yourself to ones that have good contrast. Personally, I’d prefer all the opcode names to be the same colour; the white glare from BUILD_MAP and BUILD_SET has a distracting effect on me when reading the neighboring instructions.