Fallback for imported variables

[atom]

Fallback for imported variables

[braver]

isotope-ui relies on the syntax-variables to set the @syntax-background-color. This creates a problem if the syntax-variables file contains variable names that are also used in the ui theme. Because my theme started as a copy of the One theme, that tends to happen :). In this case I'm also using a @theme-color variable and that creates a recursion.

So, I can (and will in a moment) fix it on my end.

However, we may need a rule that syntax-variables and ui-variables files stick to the required values, to make them safe for importing. These files being the "API" to pass style across packages might require some strictness here. Anything else should perhaps be moved to a different file.

[simurai]

@braver I think you can keep it as is and it should be fixed in One. Isotope works for all other themes I tested. It's just that I set it up like this:

// colors.less
@syntax-contrast: ...;
@syntax-base-color: ...;


// syntax-variables.less
@import "colors";
@syntax-background-color: darken(@syntax-base-color, @syntax-contrast);

Now when Isotope UI tries to use the syntax-variables.less there is an error because the variables from colors.less are missing.

So as a convention we could say that syntax-variables.less shouldn't rely on other files. That way other themes/packages can import it without breaking.

[braver]

I renamed @theme-color and Isotope now also works with One-syntax, so that made the problem go away for my theme. I still think that introducing undocumented variables in syntax-variables (or ui-variables for that matter) might cause problems for packages as well.

[simurai]

You're right.. the conflict was @theme-color. I thought that it would just get overridden if you import it.

Ok, closing this for now. But yeah.. we'll have to look into it once the theme settings get added.