Closed growse closed 3 years ago
Thanks for pull request, but I don't see any use cases for runtime modules. To my knowledge people don't change theirs prompts often, so recompiling should not be a problem.
If you provide valid reasons for it, we could add separate binary with runtime module.
P.S. I know that git wastes most of the time, but I don't think there's anything I can do about it.
In my case, I package this up as a single deb and distribute it across a range of machines, ranging from workstations to servers to embedded devices. Rather than having to make a separate package for each flavour of modules, it'd be good to have the option of shipping a single binary and enable/disable modules from my dotfiles depending on the machine facts.
It's not a common use case, I realise, but it's nice to have the option.
I did consider adding this as a separate binary (I was going to call it powerline-flex
for no good reason), but it seemed a bit neater tucking it behind a feature.
Hi!
Thanks for doing powerline-rust. I wanted to see if it was possible to implement runtime module selection without adversly affecting startup time too much (I run this on some rPI zeros, so am pretty sensitive to this).
I think I've got a reasonable solution here. Checking the flamegraphs, the bulk of the default configuration's time is spent in libgit (on my systems at least) and a build of this running on an rPI zero has an imperceptable difference in execution time. Flags are simply parsed as matching against a magic keyword for each module, a "-" prefix disables the module. Defaults are the same as without the feature. Whole thing is a non-default cargo feature so this is only enabled if the builder wants it.
I'm a bit of a rust newcomer, so there might be a better / more efficient way of checking for args presence and module enabling, but this way seemed to work.