Closed odisseus closed 4 years ago
I'm not sure anymore that my previous reasoning is correct. At least part of the issue is caused by the fact that
Somehow there are objects of type
fury.strings.Theme
with name"nocolor"
that are not equal toTheme.NoColor
which in turn is probably caused by the way the OGDL configuration is deserialized into objects.
The pull request #909 provided a workaround for this particular problem, but the config parsing issue is still there.
I think you're right that the OGDL isn't serialized in the best possible way. The Theme is saved structurally, which means you can configure each and every color if you want to edit the config file, but we should just store the name and look the theme up by name from the three options.
This issue is highlighted by the current state of the "wildcard-expansion" integration test.
The messages about the interaction with the BSP server (defined in
fury.core.BloopServer#connect
) are logged with the correct theme when Fury is invoked as a daemon, because the theme is set by a previous command and stored in avar
.However, in standalone mode, the memory state for the current command is not affected by the previous commands. As a result, some log messages get to use the default
Config
, which happens to use the "basic" theme.