-
Notifications
You must be signed in to change notification settings - Fork 230
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify theme usage #896
Simplify theme usage #896
Conversation
Nice! Do all the preview-*.nu scripts still work? |
I'm ... uh, not sure! What and where are they? |
Also not sure why CI is failing. Is |
In the themes directory. It's what I used to generate all the screenshots. |
I'm not worried by the CI, it doesn't work very well. |
Ah yeah - Just found theme a few seconds ago. Probably needs updating - Brb ;-) |
I think it's a simple change, but:
As I work on this, do you have a preference on what the directory should actually be named? I'm good with either one, but it seems like it's been changed at some point. |
I'm fine with the current name for folders but I've always thought the preview scripts belonged in a different folder since they're not themes. I just left them in there because it was just easier to generate the theme images. I wrote those on Windows, but I wouldn't be opposed to having a version that works on Linux or MacOS. |
I'm going to work on updating it so it will at least run on WSL and Windows native, but I don't have a Mac or pure-Linux (even virtual machine) at the moment. I'm thinking we should at least move the screenshot code to a closure that can be run based on the host system. Then people can add screenshot code in the future for other platforms. Anyway, I'm going to do some refactoring on it, and I'll commit more later - Probably tomorrow. |
I was playing with this PR this morning. I'm not a super fan of having double the files with the *_colors.nu files. I also couldn't try any of the themes without being in the nu-themes folder. Maybe I'm just looking at it too early and it's not done yet? |
As I was working through your preview scripts, I noticed that the main README and process for setting a theme has always been ... very wrong. The modules here only set the The latest commits fix this. While I could, of course, set the terminal colors and Okay, now back to working on the preview scripts - They should be much easier now. |
Ah yes, definitely wasn't done yet (and still isn't). But it should have been "workable" in that state.
I've tried every which way that I can to have a module that has the color definitions and can be For most users, they'll just Users who prefer the older scheme (which I do) can load the definitions separately with |
I really don't want to have double the files for themes. It just makes them way more cumbersome. |
Does it help that the files are now in a separate folder? Otherwise, I think we're going to have to just throw away the PR (and that's okay), since we can't obtain the color definitions any other way without also changing the colors. That's not how it worked before, and I really don't want to lose the ability to set the I can put in an enhancement request for a way to do this in a single module, and then we can revisit if that gets implemented. Or, we can go with the second module and fix it if that enhancement gets implemented. I'm okay with any path. |
Hmmm - One more thing to try to get them in a single file ... Probably won't work, but crossing my fingers. |
Well, it didn't, but eventually I came up with something that allowed me to get rid of the duplicate module files. @fdncred Thanks for pushing back on this. I didn't like it either, but I just hadn't found a good alternative. I think I'm happy with the latest iteration, and I hope you will as well. The interesting thing about where I ended up is that it is fully backwards-compatible with the older version. In other words, this still works exactly the same: > use ./themes/nu-themes/<theme_name>.nu
> $env.config.color_config = (<theme_name>) But that still leaves the terminal colors untouched. If the user wants to set everything in one step, they will source ./themes/nu-themes/<theme_name>.nu Note: I was trying to have two different submodules in the same file, but there seems to be a Nushell bug that prevents the Side-note: The |
Next up, if @fdncred is okay with this version, is to work on the preview scripts. They should still work on your system since the module-usage is the same once again. But I still hope to make them more universal. |
Indeed, it's always been like that. That's why there was a 3024r.nu 3024-day.nu and 3024-night.nu. Yup, I'm fine with this. Nice touch maintaining backwards compatibility. I commented on your issue already about the other bug you found. Let's go! |
Darn it! I just noticed this. These need to be restored, I think. Thoughts?
I don't want to lose these additional themes. |
@fdncred I'll probably figure this out about the same time you answer (seems to commonly be the case ;-), but were those manually defined or sourced from somewhere else? |
No worries. Manually defined from contributors. |
Ok, I'll add them back in, and hopefully in a way that they won't get lost again since they'll be generated by |
@fdncred Question on the I'm guessing that there was some limitation when you wrote it that required generation of a separate |
No objections if it works. It's been a while since I wrote that so I don't remember exactly why I had to do that. |
Primary change: Simplifies theme usage by adding an
export-env
to each theme so that$env.config.color_config
is automatically set when importing the module.Rather than the old:
It's now a single-step:
Updates
make.nu
to create the theme files (uses the previously addedstr dedent
for clean output).A couple (literally, 2) of the remote themes did not have all necessary colors and failed. Updated
make.nu
to continue on error, but report the failures.Updated
README.md