New features (TBD)

[babarot]

zplug v2.0.0 specifications

• New project directory
  • consists of multiple files
  • autoload (__subcommand__ file)
• External commands like git(1)
• Test
  • use zspec as testing framework
  • tests for each files
  • integration testing
• Documentation (man pages)
• Rename tags (TBD)
  • as => type
  • of => use
  • file => rename / as
  • ...
• Notification
  • AppleScript, terminal-notifier (OS X)
  • notify-send (GNU/Linux)
• Lazy loading
  • use autoload (e.g. mollifier/cd-gitroot)
  • lazy:"~/path/to/file"

[babarot]

New tag name

• file tag

  The name of file is difficult for the users. rename? name?

[NigoroJr]

I know this will be confusing to current users (and also breaks backward compatibility), but maybe:

Current	Proposal	Example
as	is_a (or isa like Perl?)	zplug "mollifier/zload", is_a:plugin
file	as	zplug "dominictarr/JSON.sh", is_a:command, as:jq
of	use	zplug "rupa/z", use:z.sh

I think your idea of using name is also a good one because you can write it like zplug "user/repo", from:github, at:tag, is_a:command, name:foo, use:bar.sh (English: "user/repo from github at tag tag is a command named jq using bar.sh")

[babarot]

@NigoroJr

👍 Thank you for your suggestion !

I see 😎 . It's true that as is the better than file, but is_a as as tag is not beautiful so much...let me see

[asymmetric]

I always found of to be counterintuitive. What about path?

Also, what do you think of type instead of as?

[babarot]

@asymmetric

I always found of to be counterintuitive. What about path?

Thank you for your suggestion. It is true that of is counterintuitive tag for us.

Also, what do you think of type instead of as?

Great

[babarot]

Now

Current tags	Alternatives
of	use > path
as	type > is_a
file	as

[asymmetric]

Another option for of is filter, as in Ruby and many other languages.

[babarot]

@asymmetric i see. Please tell me more exactly.

[jedahan]

Can you have multiple use per zplug?
If only one use per zplug, then maybe zplug "rupa/z/z.sh"

[jedahan]

I like the following changes

• as → type
• file → alias
• of → file

zplug "dominictarr/JSON.sh", type:command, alias:jq
zplug "mollifier/zload", type:plugin
zplug "rupa/z", file:z.sh

[jedahan]

Some of the confusion may be in mixing of different parts of speech.

adverb as
preposition of, from, at
noun commit, file, nice
adjective frozen
verb do, ignore

The proposal above makes things more noun-centric.

preposition from, at
noun commit, alias, file, nice, type
adjective frozen
verb do, ignore

I am not sure if this is easier or harder.

[babarot]

Thank you all.

I think the users should use like natural language to set the plugins tag. In other words it's like this:

English: "user/repo from github at tag tag is a command named jq using bar.sh"

Because the description by natural language is very intuitive, there are no problems even if we forget the tag name.

[asymmetric]

@b4b4r07 the filter function in many languages means "filter only the values that match". In this sense I think it's better than other candidates like file, because it applies to both filenames - e.g. filter:z.sh - as well as to globs: filter:*.zsh.

[babarot]

@asymmetric I understand. Thanks

[babarot]

• Support autoload like Vim #43
• Notification feature #77

[NigoroJr]

@b4b4r07 I was wondering, for the as:completion feature, it might help to have a $ZPLUG_HOME/completions (the name can of course be different) that has a collection of completion files (_*). This way if there is a bunch of _* files in a directory and if you want to use just one of them, it can be symlinked to that $ZPLUG_HOME/completions directory, which can then be added to $fpath rather than adding directories per plugin. This is similar to how as:command is processed. For example,

$ZPLUG_HOME/user
`-- repo
    |-- _bar
    |-- _baz
    |-- _foo
    `-- _git

if you want to use the _foo completion but not _git, you can write:

zplug 'user/repo', as:completion, of:'_foo'

zplug will then perform something equivalent to:

ln -sf $ZPLUG_HOME/user/repo/_foo $ZPLUG_HOME/completions/
fpath=($fpath $ZPLUG_HOME/completions)

When writing of:_foo, it currently gets sourced, but with the as:completion tag, I think this will be possible.

[babarot]

@NigoroJr
Hi, I can't agree with you more!

The new as: value (as:completion) will similar to as:plugin. The tag and value will be implemented as what you said.

[babarot]

Currently, the main file (zplug) is beyond the 2000 lines.
I'm planning to divide the main file to improve the outlook of source file entire.

Like this:

.
├── Makefile
├── README.md
├── autoload
│   ├── commands
│   │   ├── __check
│   │   ├── __clean
│   │   ├── __clear
│   │   ├── __install
│   │   ├── __list
│   │   ├── __load
│   │   ├── __status
│   │   └── __upload
│   ├── utils
│   │   ├── job.zsh
│   │   ├── logger.zsh
│   │   ├── parser.zsh
│   │   ├── spinners.zsh
│   │   └── validator.zsh
│   └── zplug
├── bin
│   └── zplug
├── completions
│   └── _zplug
├── doc
│   └── man
│       └── man1
│           └── zplug.1
├── lib
│   └── lib.zsh
├── test
└── zplug.zsh

I think zplug's strong point is that it is a single file. via #31

When we could break the regulation, we should be able to find new benefits.

[babarot]

Image:

[babarot]

Hi, there

I have been developing zplug version 2.
zplug v2 has many new features and bug fixes.
For example, zplug main file was devided in order to easier to maintain and provide excellent performance.
Furthermore, in new zplug, it will become easier to use for the users because many zplug tag names will be renamed.

BTW, upon that implementations, we need to decide new tag name.

Which tag name do you think is best? Does your thinking change?

@NigoroJr @asymmetric @jedahan

[NigoroJr]

@b4b4r07 Awesome, great work! I like @asymmetric's idea of using type so I'll vote for the following tag names.

Current	New
of	use
as	type
file	as

[babarot]

@NigoroJr 👍 Thanks. Certainly, I think this change is a very intuitive and easy to understand.

In addition, I'm rethinking the directory structure that manages plugins. Currently, it's $ZPLUG_HOME/repos/USERNAME/REPONAME, but I'm thinking $ZPLUG_HOME/src/github.com/USERNAME/REPONAME. I am aware of the little golang directory structure. Like this:

Shoud I leave this as it is?

[NigoroJr]

I think that's a good idea and I can see at least two scenarios where that would be useful.

1. There will be no name colision even if someone has the same repo name on both github and bitbucket
2. It will be easier to delete all the repositories from a source (for example, if you want to delete all the plugins downloaded from github you can just delete the github.com directory.

However, I'm not sure if github.com is the right name to use for the directory name. Since the from tag can be github, bitbucket, gist, or gh-r, maybe it's better to use those names for consistency rather than github.com etc. ?

[jedahan]

Comments on previous proposals

1. I really like src/github.com/USERNAME/REPONAME. It is clear, and does not require maintenance of special supported places to get repositories.
2. @NigoroJr with your example above, we would have a config like the following?

zplug "dominictarr/JSON.sh", type:command, as:jq
zplug "mollifier/zload", type:plugin
zplug "rupa/z", use:z.sh

as reads weird to me, because it can be used in the english sentence "user/repo from github as command with alias jq", versus "user/repo from github is type command as jq". Both of those sentences feel just as strange as one another.

Feature proposals

1. Option to specify the source url in zplug, like zplug "git.jedahan.com/jedahan/aliases". Default to github.com
2. Option to specify the of path in zplug, like zplug "rupa/z/z.sh", default to init.zsh (fallback to REPONAME.zsh (fallback to REPONAME.plugin.zsh)).
3. If NO on Support oh-my-zsh plugins #2, rename of to from (or load, or read)
4. Maybe split zplug into zcommand, zalias, zplugin, and zplug? This proposal do not like so much right now, but maybe some other people like it?
5. Rename as to alias

with #1 and 2

zplug "dominictarr/JSON.sh", type:command, as:jq
zplug "mollifier/zload", type:plugin
zplug "rupa/z/z.sh"
zplug "git.jedahan.com/dotfiles/aliases.zsh"

with 1, 2, 4, and 5

zcommand "dominictarr/JSON.sh", alias:jq
zplugin "mollifier/zload"
zplug "rupa/z/z.sh"
zplug "git.jedahan.com/dotfiles/aliases.zsh"

Patiently awaiting zplug v2.0, to play around with different ideas.

[NigoroJr]

@jedahan Great insight on the as tag. I wonder, however, if alias is the best choice because it suggests that you can also use the jq in addition to JSON.sh In reality, zplug puts JSON.sh in PATH as a different name (i.e. jq). What are your thoughts on this?

[asymmetric]

I'm actually curious: what's the usecase for renaming in the first place?

Other than that, I'm 👍 with @NigoroJr's suggested keywords.

[NigoroJr]

@asymmetric For example...

• if you have two repositories that have the executable names
• if you want to change the name of the distributed executable (like fzf-bin)

[asymmetric]

I see. I'm ok with as:, but an alternative could be name:.

[babarot]

Thank you all 👘

I won't change basic zplug format like this: zplug "username/reponame", tag:value. Because I think the format is unified and easy to understand for many users. In addition, I'm not planning to split zplug command such as zcommand, zplugin, …

zplug's new project directory is the following:

Thanks to autoload, zplug will be more fast. In addition, we are easier to maintain because all aliases in zsh are not expanded if -U option is passed in autoload.

[babarot]

zplug v2, like git(1), supports external commands.
These are executable scripts that reside somewhere in the PATH, named zplug-cmdname,
which can be invoked like zplug cmdname.
This allows you to create your own commands without modifying zplug's internals.

[NigoroJr]

@b4b4r07 Looks fantastic! Is there anything I can do to help?

[babarot]

@NigoroJr

It will be easier to delete all the repositories from a source (for example, if you want to delete all the plugins downloaded from github you can just delete the github.com directory.

I found this problem that there is no consistency. Really I want to adopt the following directory structure:

.
├── bin
├── completion
└── src
    ├── bitbucket
    ├── gh-r
    ├── gist
    ├── github
    └── local

8 directories, 0 files

However, there is a contradiction in above. At first, No "local" directory is required because zplug will source local plugins file immediately. Next, I want to adopt as:{plugin,command,completion}/from:{github,bitbucket,gh-r,gist,local} directory structure but,,,:

.
├── command <- bin is better than command
├── completion
└── plugin    <- plugin is not better name
    ├── bitbucket
    ├── gh-r
    ├── gist
    ├── github
    └── local    <- no need

8 directories, 0 files

In addition, the installation method by using git.io/zplug became deprecated because zplug main file is divided. Therefore, the user need to install with git clone URL ~/.zplug, but in that case, there is a need to share with zplug's repository.

[jedahan]

maybe name or rename instead of as or alias

[babarot]

I'd like to prefer rename to name because we may confuse name tag with use tag.

[babarot]

See top comment

zplug v2.0.0 specifications

• New project directory
  • consists of multiple files
  • autoload (__subcommand__ file)
• External commands like git(1)
• Test
  • testing framework zspec
  • tests for each files
  • integration testing
• Documentation (man pages)
• Rename tags (TBD)
  • as => type
  • of => use
  • file => rename
• Notification
  • AppleScript, terminal-notifier (OS X)
  • ???? (GNU/Linux)
• Lazy loading
  • use autoload (e.g. mollifier/cd-gitroot)
  • lazy:"~/path/to/file"

[NigoroJr]

@b4b4r07 notify-send is probably the command for GNU/Linux.

[babarot]

@NigoroJr 👍 Thanks! but I don't have GNU/Linux desktop machine...

[asymmetric]

@b4b4r07 I do! What do you need tested?

And anyway, you can use vagrant to easily bring up any VM! :)

[asymmetric]

About rename:, the problem I see with it is that it sounds weird: rename:jq doesn't make much sense as a sentence. rename_to: would be more correct.

[babarot]

Closing! see also #121