Skip to content
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

Merged
merged 4 commits into from
Mar 1, 2023
Merged

New way to add plugins #250

merged 4 commits into from
Mar 1, 2023

Conversation

neiromaster
Copy link
Contributor

@neiromaster neiromaster commented Feb 28, 2023

License Acceptance

  • This repository is Apache version 2.0 licensed (some scripts may have alternate licensing inline in their code) and by making this PR, I am contributing my changes to the repository under the terms of the Apache 2 license.

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

  • A helper script
  • A link to an external resource like a blog post or video
  • Text cleanups/updates
  • Test updates
  • Bug fix
  • New feature
  • Plugin list change

Checklist

  • I have read the CONTRIBUTING document.
  • I have updated the readme if this PR changes/updates quickstart functionality.
  • All new and existing tests pass.
  • Any scripts added use #!/usr/bin/env interpreter instead of potentially platform-specific direct paths (#!/bin/sh is an allowed exception)
  • Scripts are marked executable
  • Scripts do not have a language file extension unless they are meant to be sourced and not run standalone. No one should have to know if a script was written in bash, python, ruby or whatever. Not including file extensions makes it easier to rewrite the script in another language later without having to change every reference to the previous version.
  • I have added a credit line to README.md for the script
  • If there was no author credit in a script added in this PR, I have added one.
  • I have confirmed that the link(s) in my PR are valid.

@codeclimate
Copy link

codeclimate bot commented Feb 28, 2023

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]>
Copy link
Owner

@unixorn unixorn left a 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.

zsh/.zshrc Outdated Show resolved Hide resolved
@unixorn
Copy link
Owner

unixorn commented Feb 28, 2023

@neiromaster
Something was nagging at me and I remembered what it was. It's not an inherent problem with having the plugins get loaded from a directory like this, but with how the kit currently determines when to regenerate init.zsh

Currently, the kit (inside ~/.zgen_setup) looks at the modification dates of REAL_ZGEN_SETUP, which is either ~/.zgen-local-plugins or when present, ~/.zsh-quickstart-local-plugins, and calls setup-zgen-repos which creates a new init.zsh.

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 init.zsh every session startup.

Something with the directory's modification date?

@unixorn
Copy link
Owner

unixorn commented Feb 28, 2023

Hit submit too soon.

Add a check of the directory's modification date and ~/.zgenon/init.zsh so that we call setup-zgen-repos if the directory has been updated too.

@neiromaster
Copy link
Contributor Author

I'm going to think about how to solve this problem. I may have to check every file

Copy link
Owner

@unixorn unixorn left a 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

zsh/.zshrc Show resolved Hide resolved
@neiromaster
Copy link
Contributor Author

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

@unixorn
Copy link
Owner

unixorn commented Feb 28, 2023

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 00-everywhere, 01-personal-only-plugins and 02-work-only-plugins files?

I appreciate the contribution, I'm always interested in ways to customize the kit that don't require users to maintain their own forks.

@neiromaster
Copy link
Contributor Author

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?

@unixorn
Copy link
Owner

unixorn commented Feb 28, 2023

Go ahead and do the code and I'll add some examples of all/home/work files into the readme

@neiromaster
Copy link
Contributor Author

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 zgen-setup and zqs update. This is old behavior. Perhaps it would be a good idea to add a command to zqs to clean up the saved files so you don't have to do it manually

@unixorn unixorn mentioned this pull request Mar 1, 2023
@unixorn
Copy link
Owner

unixorn commented Mar 1, 2023

Go ahead and add your code here, then we can add zqs cleanup in #252

@neiromaster
Copy link
Contributor Author

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
Copy link
Owner

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.

@unixorn unixorn merged commit b750af7 into unixorn:main Mar 1, 2023
@unixorn
Copy link
Owner

unixorn commented Mar 1, 2023

Thanks for the contribution!

unixorn added a commit that referenced this pull request Mar 1, 2023
Update the plugin customization section of the readme now that
#250 is merged.

Signed-off-by: Joe Block <[email protected]>
seanb4t pushed a commit to seanb4t/zsh-quickstart-kit that referenced this pull request May 12, 2023
Update the plugin customization section of the readme now that
unixorn#250 is merged.

Signed-off-by: Joe Block <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] command not found: zgenom
2 participants