Select currently applied theme on startup

[arunvelsriram]

Am trying to select the currently applied theme on startup. Am planning to use the value in colors.name for this.

For example,

colors:
   name: 3024.dark

I have made few changes. However I noticed that for some themes name is missing. Also the names are not matching the filename. Would it be possible to add name to all themes and keep it same as filename or vice-versa.

[arunvelsriram]

Actually it will not work. I thought we are writing the name to alacritty config file as well. But that's not the case.

Another approaches I can think of is making alacritty-themes save the applied theme name to filesystem. What do you think?

[rajasegar]

I think we should write the name to alacritty.yml , but we have to be aware that we are adding custom key values in std config file. And having a separate file for just theme name doesn't sound like a good approach to me. I assume the intention here is to know what is the currently applied theme for alacritty right? Otherwise we should follow an entirely new approach like color schemes mentioned in the wiki https://github.com/alacritty/alacritty/wiki/Color-schemes With this approach we can have the advantage of saving the theme name in the config file itself and apply whatever theme from the list of themes. But for this we need to make considerable changes in the code right now.

[arunvelsriram]

I think we should write the name to alacritty.yml , but we have to be aware that we are adding custom key values in std config file.

I think this would be a better option as it involves minimal changes to get the required feature. We have to make sure all themes has name and they match the file name.

Otherwise we should follow an entirely new approach like color schemes mentioned in the wiki

Yes the approach suggested in the doc using YAML anchors is nice. But requires more changes. As well as we need to think about how much theme definition to have in the user's config file. If we have all the definitions then it might be noisy.

Am leaning towards using the name key.

[detj]

but we have to be aware that we are adding custom key values in std config file.

Adding any non-standard key may be a problematic approach. There could be other tools like alacritty-themes that the user may want to use and those tools may break or not parse the colors dictionary as expected.

There are 2 approaches I can think of to handle this situation.

1. Match the whole colors dictionary to determine active theme

• Don't add and rely on name & author fields
• Do a quick string match on the whole colors dictionary. If they are === same, then you'd know which theme is active
• This could be a little resource intensive, but then again, this needs to run at startup only. That overhead may be fine.
• If no theme matched for whatever reason, like if the user had edited one color value manually, then alacritty-themes will behave how it behaves today. Maybe, it can also log that it failed to determine the active theme. This enhancement remains progressive.

2. Track name and author field in comments

Another way would be to, add and track the name & author field as part of yaml comments.

• This way, we stay away from non-standard fields.
• Not every theme has name & author fields. Behavior degrades, if it cannot determine the theme. Around 27% of themes do not have "name" & "author" fields. I calculated.
• No apparent harm if the comment is edited or not found, degrade gracefully
• See #54

I like approach 1 better. Because it has less dependencies provided if the overhead of matching theme at startup works out fine.

What do you think?

[JuanVqz]

Hi @detj,

To me, both approaches are valid and good enough to do it, I like the first one, though.

Thank you for your valuated opinion.

[JuanVqz]

We implemented a flag called --current and you can trigger it before changing your current theme