Closed ninrod closed 6 years ago
I'm gonna be honest with you. Although I use zsh for years, I haven't used any of zsh plugin managers and I don't know much about them. Could you please kindly explain to me which plugin managers need this type of structure? Especially why we need src/_zsh-system-clipboard
file?
it's just a convention. I don't use a plugin manager either, just a tiny function I wrote here.
anyway, the main idea is that the plugin or whatever will have a list in the form author/repo. it expects that the repo will have a file called repo.plugin.zsh that will take care of loading the required files. that's it.
If you just rename the file to zsh-system-clipboard.plugin.zsh I'm sure it will work too. But with this pull, it is already working, I just tested it.
I understand the .plugin.
suffix is needed but I was asking about src/_zsh-system-clipboard
file? Do we need that for plugin managers or it's just a convenient way for users to import the plugin via autoload
calls?
the main idea here is that the .plugin.
file is going to source everything that lies inside the src/
folder. In your case, as you have only one file to be source, we could actually just have the .plugin.
file and be done. If you grow your plugin to have more files, then the src/
approach will going to be handy.
I understand, thanks again. I'll also experiment later splitting the plugin into files and autoloading them on demand. For example, only these lines need to be loaded initially. I can autoload other ones. What do you think about that?
I appericated the efforts again. I didn't like the idea of src/_zsh-system-clipboard
file for now and I removed it in 0339006a8f77c415c80ced2393ab6119af14a429. When I add more key bindings to this plugin, I'll autoload them as I said above via autoload
.
@kutsan, yes that is way simpler. you could actually just have one file, the .plugin.
file and be done. the symbolic link is really not needed if you do this.
In second though, I think that the src/ approach only works for compdef stuff. Your will not load if I implement the src/
approach. But I don't know why. I think compedef functions behave differently in some way.
For example, only these lines need to be loaded initially. I can autoload other ones. What do you think about that?
That seems to be very interesting, but to be honest, you knowledge about zsh scripting already surpasses mine by much, so I don't think I'll be of much help in this regard. For instance, I don't understand autoloading in zsh.
you could actually just have one file, the
.plugin.
file and be done.
I don't think that's the convention to be honest. As far as I see everybody has two files in their plugin repository, like zsh-syntax-highlighting and zsh-autopair. So, I don't want to delete zsh-system-clipboard.zsh
and but rather have .plugin.
file and that.
I think compedef functions behave differently in some way.
Yes, I know what you are talking about but currently we don't need src/
approach for now.
That seems to be very interesting, but to be honest, you knowledge about zsh scripting already surpasses mine by much, so I don't think I'll be of much help in this regard. For instance, I don't understand autoloading in zsh.
Normally, when you write a function inside your .zshrc
file, this function and its body will be loaded for every new shell prompt. If you don't use that function very often, it'll slow you down with couple of milliseconds at startup. So, there is actually no need to load its function body but only we need to define it and load its body on demand when we call it.
To create a function like that (i'll keep saying that function but it's actually just a file), you need to put that function under somewhere in your $fpath
. So echo $fpath
to see your $fpath
value and cd $fpath[1]
to cd
first one (or choose another one). Now create a file there named ninrod
(without any extension) and put echo "hey"
inside it. And now in your zsh prompt, you can use autoload ninrod
, your function will be defined, not loaded. Then, you can use ninrod
to load and call it. It should print hey
.
Moving further, you can even compile those functions into binary-like format with built-in zcompile
utility. It's like machine code but only zsh can understand it. That way it will loaded lots lots of faster.
What I was trying to say is for the project, I can use this approach and load the plugin functionality when user invoke it with a key binding. It will be faster.
hi, please review