Thanks for the PR!

I am a bit split on this, as we originally intentionally ignored support for cterm* because it added key ambiguity. Now that we support a looser attribute list, more in-line with nvim_set_hl, it feels like the support should be there.

If we add support for ctermfg/bg we should also support the cterm attribute map. It's unclear what the correct behaviour is when provided separate bold = true attributes in this case. Should they be merged into a cterm key in the exporter? How can we know when to include that value and when to not (as most of the time people probably dont want it generating noise, and defaulting it to cterm=NONE is also probably incorrect.)

I think, probably we just say cterm, ctermfg and ctermbg are not "officially supported" but the key-values are passed through as a kindness if the user provides them.

Can you also add:

• doc updates

  • accepted keys to "direct definition" with the not "officially supported" caveat.

• test updates

  • key-check in this test (bonus if you add the formatting attributes I missed in the last update)

The import script should probably be updated to go along with this change as well.