-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Simpler configuration file #2586
Comments
How can the latter part be implemented, the one where users can apply additional overrides? Specifically, how will the users know which overrides they can apply? How can I ensure that all overrides that users apply will have the same effect even after I modify the wizard to produce different baseline configs? |
Would it be possible to use a minimal configuration set (like that above) to regenerate a .p10k.zsh file without any user prompting? This would make it quicker to create an updated 'gold' configuration. The new gold could be compared with a previous gold to check if any new and interesting features had been added. |
That would require making a commitment to keep the questions in the wizard backward compatible with the past answers. Currently there is no guarantee of this kind: the next version of the wizard can have dramatically different questions. |
How often does that happen? A configuration var that gets changed/incremented when a change to the questions occurs could be used to a) force reprompting the user, b) indicate to the user a need to regenerate a new .p10k.zsh Realize here the interest in this is because powerlevel10k is incredibly awesome and also allows for extensive user customization. As such, users want to stay current with your latest changes and potentially incorporate those changes into their heavily customized setup. Maybe the goal isn't doable, but it is desirable. |
That's not the right question. I won't break user shells by my changes in the powerlevel10k code. This commitment is not cheap. Right now I can make any changes to the wizard without breaking anybody who isn't intentionally and explicitly pointing a gun at their own foot. I want to keep this freedom as it allows me to provide the best user experience for new users and for the 99% who don't manually edit their configs. You don't need to run the generator to stay up to date. Update powerlevel10k at any time and subscribe to new releases on GitHub. If anything in the release notes seems of interest (should be less than once a year even for prompt enthusiasts), edit your config. |
I'm not familiar with how the wizard works but some ideas are:
Well, that gets back to having better documentation (see #1112) although at least for now, you could just point to the config/p10k-classic.zsh file as a source of documentation.
I don't think you need to. If you go the route of having p10k generate config from another source file, then the base config won't change unless the user calls p10k configure again, at which time the user can update their overrides if needed. If you do something like have functions like I describe above, it's a little more difficult because you would need some level of backwards compatibility for those functions, but hopefully that wouldn't be too much of a burden. |
If this is good enough for your needs, you can do this: source ~/.p10k.zsh
source ~/.p10k-overrides.zsh I appreciate the ideas you've listed but at this point the lack of ideas isn't the problem. If you really care about this issue, fork the project and implement your ideas. It's unlikely that I'll be doing anything in this area myself. |
If you have custom (not customized, but completely new) segments, wouldn't the user need a .p10k-pre.zsh ? |
Need |
to add a custom segment that can then be included in a particular left/right prompt element. by your response, i'm assuming i'm being unreasonably paranoid about using an item before it is declared. |
Not necessarily. It just needs to continue supporting the same inputs as previous versions.
The problem is that currently, this is somewhat difficult to do, due to the size and complexity of the config file.
I'll consider it, but I think it would be a lot easier for someone already familiar with the p10k codebase. And I don't currently have a lot of time to learn it. Four years ago you said:
Has your opinion changed since then? Are you no longer interested in addressing this pain point? The more I think about this, the more I think that the best way to handle it is to have functions to simplify settings, so that for example instead of having to set a handful of variables for the frame, you can just call a function that sets all of them. Or call a function that sets the color scheme. Although you still have tons of configuration for segments you don't use..... |
As an additional point, much of my customization is commenting out all the stuff I don't use. With everything left, in, 'env' becomes a nearly useless command to use to check for new/unintended settings. I'd much prefer an 'opt-in' method for a setting than having everything just defined - but I'm probably in the minority. |
We have a disconnect here. I hope you'll forgive me for not elaborating. I don't have anything new to say on this topic.
No.
As interested as before.
I'm not sure I understand. You can define a prompt segment after sourcing |
That's the way. You just need to make an extra step and stop running the wizard. You won't miss out on anything if you do. Save yourself time and energy. My own config is here: https://github.com/romkatv/dotfiles-public/commits/master/.p10k.zsh. It's 167 lines, including empty ones. There were two changes in 2023: the second change reverted the first. The previous change was in 2021. |
Closing because I don't intend to do anything here. |
I know this is closed, but a tip is use git to version control your patched .p10k.zsh. Have one branch for the generated and one branch for the match and use git merge. |
The
p10k configure
wizard is great. It lets you quickly customize the prompt.However, the resulting
.p10k
file that is generated is, well, overwhelming.It generates a shell script that is almost 2000 lines long. Part of this is because this configuration file appears to also serves as the main source of documentation for configuring p105 (see #1112).
If you just want to use the theme exactly as generated by the wizard, this is all well and good. But if you want to actually tweak the result a little bit, then it isn't really ideal, for a few different reasons:
p10k configure
again, say because you wan to change one of the decisions you made the last time you ran it, then it overwrites any other changes you made in the configuration, and you have to then do a diff with the backup file and figure out which changes are from running the configure script, and which were tweaks you made.What I propose, is that there is a way to have a configuration file that would specify the options you can choose in the wizard, and override additional parameters as desired. Then either allow passing that as an argument to
p10k configure
to generate the current format of the configuration file, or allow using that as the configuration file.For example you might have something like:
The text was updated successfully, but these errors were encountered: