rajasegar / alacritty-themes

:rainbow: :lollipop: Themes :candy: :heart_eyes: for Alacritty: A cross-platform GPU-accelerated Terminal emulator
MIT License
707 stars 71 forks source link

Consider using include syntax #177

Open shmup opened 2 years ago

shmup commented 2 years ago

Instead of adding many configurations to the user's alacritty.yml, you could simply append (or replace) an include:

import:
  - /home/jtm/.config/alacritty/themes/dracula.yml

Making a 1 line change seems pretty solid. Maybe you've considered and want the current solution to be standalone (not requiring other files).

shmup commented 2 years ago

Whoa, I didn't even know about the scheme syntax! I am learning so much :3 (I only recently learned about imports heh)

https://gist.githubusercontent.com/sainnhe/ad5cbc4f05c4ced83f80e54d9a75d22f/raw/939021739051393ceff88d3df014fb5e4e90e7aa/gruvbox-material-alacritty.yml

JuanVqz commented 2 years ago

this sounds good, have a question.

do you know if you can use more than one import? if so, how will we know which one is the theme we want to add/remove?

Ex.

# alacritty.yml

import:
  - /path/to/some/config.yml
  - /path/to/colorscheme.yml
shmup commented 2 years ago

do you know if you can use more than one import?

You can use more than one import, and in a quick test I believe it works by merging, so:

import:
 - file_containing_foreground1_and_background1.yml
 - file_containing_foreground2.yml

Would result in using background1 and foreground2

how will we know which one is the theme we want to add/remove?

Hm. Well, a first quick idea (and note: I haven't explored how this project is currently functioning nor have I given my idea much thought):

  1. A user selects a theme with the tool
  2. We replace the contents of alacritty/selected_theme.yml with the content of the selected theme
  3. We either add that yml line to an import block or..
  4. If it exists (is already imported) we do nothing else

I just did a test where I modified a property in an imported file and when saving, alacritty doesn't detect this. It only detects changes to alacritty.yml, so in the case of #4 we'd have to solve this. I did however follow that change up with a touch alacritty.yml and that triggered the update. Just 1 technique

JuanVqz commented 2 years ago

Yep, i like the idea of having a file and change the content.

Could you please verify if applying your changes the preview works as currently is working?

shmup commented 2 years ago

What is it you'd like me to verify exactly?

I've minimally verified this concept, using a touch, but I'm not sure what you'd like me to verify for y'all. Might be happy to, just word it again if you could

https://user-images.githubusercontent.com/118710/186312618-de139657-ddc4-4615-b901-d0e6f0f12818.mp4

shmup commented 2 years ago

Unless you meant "applying your changes" as in make the functional changes to this project, I don't think I'd have time for that currently. Maybe in time though, it's good we're talking about it and making notes

JuanVqz commented 2 years ago

no, I didn't mean applying the changes, hahaha, it could take time, yes, I wanted to see how it could work as you demonstrated it in the video record.

the touch alacritty.yml action makes me think if that will work or not. :thinking:

shmup commented 2 years ago

We can still do it. The project is already using fs (obviously), and all touch is doing when I did that example is updating the file's timestamp.

fs has that too!

Little example from this video:

#!/usr/bin/env node

const config = "/home/jtm/.config/alacritty/alacritty.yml";

const fs = require('fs');
const fd = fs.openSync(config);

console.log('before', fs.statSync(config).mtime);
fs.futimesSync(fd, new Date(), new Date());
console.log('after', fs.statSync(config).mtime);

So in the case of the $USER already having the alacritty_theme.yml imported, we'd just run a fs.futimesSync(...), otherwise the modified time would be updated when we add that line to their config.

https://user-images.githubusercontent.com/118710/186539166-e72e9dc5-5f9b-4e61-89a9-5da620d97767.mp4

shmup commented 2 years ago

no, I didn't mean applying the changes, hahaha, it could take time, yes, I wanted to see how it could work as you demonstrated it in the video record.

the touch alacritty.yml action makes me think if that will work or not. thinking

hehe yeah I didn't really think you'd have meant that, but also, it might not take much time! Not if we iron out a definitive plan forward :P

JuanVqz commented 2 years ago

Something that makes me be worried about it's when the user is picking another theme, since it's an async process it could cause issues, it will be great if you can verify that as well. After that we can ask the creator of the package for his point of view.

shmup commented 2 years ago

I see, yeah I can investigate that and possibly even change the implementation idea around.

JuanVqz commented 2 years ago

btw, I may say this before but from my side, I like the idea, it seems to be secure because that way we won't need to touch the alacrity.yml a lot. and may not cause issues there, also we can add comments in the alacritty-theme.yml to indicate the previous theme and the current one, and also add links to the theme's source.

tahir-hassan commented 1 year ago

I'll be honest, this is what I thought this utility would do as it is a lot easier to manage for the user. I use Nerd Fonts for instance, which I saw disappear because of the color change.

I can work on this and submit a pull request if you guys want?

JuanVqz commented 1 year ago

guys want?

hey, @tahir-hassan sure thing! please do we appreciate it