-
-
Notifications
You must be signed in to change notification settings - Fork 92
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
New way to add plugins #250
Conversation
Code Climate has analyzed commit 8bd2cd1 and detected 0 issues on this pull request. View more on Code Climate. |
Signed-off-by: neiromaster <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor changes, but otherwise this is looking good.
…d-plugins Signed-off-by: neiromaster <[email protected]>
@neiromaster Currently, the kit (inside If we're going to load fragment files from a directory, we have to figure out a way to detect changes to it without regenerating Something with the directory's modification date? |
Hit submit too soon. Add a check of the directory's modification date and |
I'm going to think about how to solve this problem. I may have to check every file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's an ugly edge case to deal with.
If reading the directory's modification timestamp directly doesn't work, maybe loop over the mod timestamps of every file in the directory. I hate to add more loops of stuff during session startup, but that may be the only solution.
If you do end up going with the loop, make sure it breaks and calls setup-zgen-repos
as soon as it finds a modified file - no point in checking the rest of the fragments since at that point we know we have to call it.
The rest of the PR looks solid
Changing the content of a file under the directory will not change the directory’s last modification time. So we have to do the cycle. I don't think there will be too many files in there for any of the users, so I don't think it will have any effect on the launch speed at all |
I was afraid of that. Go ahead with the loop, you're right about the number of files not really affecting start speed. Also please update readme to explicitly state that a fragment in the directory can have multiple plugins inside, and that less files will mean a faster startup. Maybe include an example where there are I appreciate the contribution, I'm always interested in ways to customize the kit that don't require users to maintain their own forks. |
Can you give me a hint? Should I add the example as an image (in pseudo-graphics) in the readme or add an example folder to the repository? |
Go ahead and do the code and I'll add some examples of all/home/work files into the readme |
I was able to do the check by checking the date of the files. But if I uninstall a plugin, it still persists even after |
Go ahead and add your code here, then we can add |
…e init file Signed-off-by: neiromaster <[email protected]>
Signed-off-by: neiromaster <[email protected]>
Check my changes. I haven't written bash scripts for quite a long time, so I might have made a mistake somewhere. But locally it works correctly for me |
@@ -290,5 +290,29 @@ fi | |||
if [ $(get_file_modification_time ${REAL_ZGEN_SETUP}) -gt $(get_file_modification_time ~/.zgenom/init.zsh) ]; then | |||
echo "$(basename ${REAL_ZGEN_SETUP}) ($REAL_ZGEN_SETUP) updated; creating a new init.zsh from plugin list in ${REAL_ZGEN_SETUP}" | |||
setup-zgen-repos | |||
elif [ -d ~/.zshrc.add-plugins.d ]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for only looking at the plugin fragments if we don't already need to rebuild init.zsh
because of $REAL_ZGEN_SETUP
. Every bit of speedup helps.
Thanks for the contribution! |
Update the plugin customization section of the readme now that #250 is merged. Signed-off-by: Joe Block <[email protected]>
Update the plugin customization section of the readme now that unixorn#250 is merged. Signed-off-by: Joe Block <[email protected]>
License Acceptance
Description
The way to add plugins using a list file has been updated. The ability to add plugins as separate files has been added
resolves #242
Type of changes
Checklist
#!/usr/bin/env interpreter
instead of potentially platform-specific direct paths (#!/bin/sh
is an allowed exception)