c2compiler icon indicating copy to clipboard operation
c2compiler copied to clipboard

Control color output with C2_COLORS environment variable

Open chqrlie opened this issue 10 months ago • 5 comments

  • use style names instead of hard-coded color names
  • customize color output via environment variable C2_COLORS: eg: C2_COLORS=none, C2_COLORS="error:bright-blue, C2_COLORS="error:#d0d0d0
  • use cache to multiple calls to unix.isatty() and stdib.getenv()
  • simplify error formating in source_mgr.c2

chqrlie avatar Mar 08 '25 23:03 chqrlie

Please be Very careful with globals in combination with plugins. Since the plugins will have a different set of them. Please see the ast.setGlobals() function. It's a bit of a hack, but it's the only way to have access to the same globals atm..

bvdberg avatar Mar 10 '25 20:03 bvdberg

Please be Very careful with globals in combination with plugins. Since the plugins will have a different set of them. Please see the ast.setGlobals() function. It's a bit of a hack, but it's the only way to have access to the same globals atm..

Yes, I am aware of this problem. As long as we call color.useColor() in both c2c and in all plugins, the global color variables should be initialized and cached with the same values.

Alternately, we could make these variables members of the diagnostics or globals or another appropriate structure to ensure encapsulation and dynamic sharing with the plugins.

The globals variable in ast/utils.c2 is definitely a hack.

chqrlie avatar Mar 10 '25 20:03 chqrlie

To keep the plugins working, all AST globals need to be moved to the Globals struct)

bvdberg avatar Mar 18 '25 10:03 bvdberg

We need to discuss this on the phone, there are also some regressions

bvdberg avatar Mar 25 '25 17:03 bvdberg

This PR is flagged as a draft for now. Work in progress

chqrlie avatar Mar 25 '25 17:03 chqrlie