One thing that's better about using the theme's default style as a fallback than the default theme is that the colours will match better. For example if you have a dark theme and the default style is light on dark, then a missing style using that will still be readable, but if it takes the style from the default (light) theme, it could result in unreadable styles by default. Need to test this.

@codebrainz I mostly implemented this for things like `indicator_error` (#1185), not as a generic theme inheritance thing. And there, using the `default` style would not be very nice.

@elextr I though about implementing proper theme inheritance, but it's a lot less trivial indeed. I first tried the naive way just like this here but with an additional `[theme_info]` `inherits` key, and while it worked as expected, it wasn't really nice at any level. It only handled the `named_styles` part, and not `named_colors`, and I have no real idea in what order this is resolved so it might not even have worked properly. BTW, my idea behind this was mostly allowing users to override a small thing in a theme without having to maintain a whole "fork" of it.

We probably should rather do something like in filetypes files, and allow ```ini # inherit colors from Fluffy [named_colors=fluffy] # override some red=#ff0000

# let's be crazy, we inherit something totally different -- which doesn't really make sense, but whatever [named_styles=inkpot] # and override some comment=red,#000 ```

Or wait to come up with a way to support all what @codebrainz wishes for. But IMO full inheritance, while nice, is slightly off-topic here and would deserve its won issue :)

It's not, and if there's a good way of limiting the fallback on default to editor styles, yeah that'd probably be nice.

Since they're fixed and rarely change, a simple lookup table ought to do.

We could create that table automatically from `scintilla.iface` couldn't we?

@codebrainz ok, was just a thought