Suitability of what goes in plugins

[krisleech]

I was looking at the rails and bundler plugins and was wondering what was suitable for inclusion. Plugins seems to contain what would be a simple alias in bash or zsh, as well as functions which contain logic.

I'm guessing each function adds overhead to startup so you need to be selective about what get included...

The rails plugin currently has migrate, but of course there are lots of additional extras that could be added. For example I was thinking of porting https://github.com/krisleech/s_and_c in to the rails plugin.

Is that the sort of thing which is useful in a plugin?

I was even wondering if we need another level of granularity for plugins, e.g rails/migrations, so we can be more selective about what we do/don't use... Or am I overthinking this?

[bpinto]

Fish is smart to load a function lazily, so I believe having 10/15 functions as we have nowadays shouldn't harm load speed.

Though, I completely agree that it should have some rules around what goes in a plugin. However, at this moment, I'm trying not to be so restrict as this framework is new, and I would like people to feel at home when using it. Therefore, I'm adding alias (functions for fish) I know most of the users are familiar with.

About adding s_and_c to rails plugin, I think I consider it more as a plugin than as a function. As it's not a simple alias.

What's your input? On Mar 7, 2013 9:42 AM, "Kris Leech" notifications@github.com wrote:

I was looking at the rails and bundler plugins and was wondering what was suitable for inclusion. Plugins seems to contain what would be a simple alias in bash or zsh, as well as functions which contain logic.

I'm guessing each function adds overhead to startup so you need to be selective about what get included...

The rails plugin currently has migrate, but of course there are lots of additional extras that could be added. For example I was thinking of porting https://github.com/krisleech/s_and_c in to the rails plugin.

Is that the sort of thing which is useful in a plugin?

I was even wondering if we need another level of granularity for plugins, e.g rails/migrations, so we can be more selective about what we do/don't use... Or am I overthinking this?

— Reply to this email directly or view it on GitHubhttps://github.com/bpinto/oh-my-fish/issues/18 .

[bpinto]

I don't use bundler's be and bi alias for instance... :)

[krisleech]

Good to know about lazy loading of functions :)

Totally agree with what you said, a new project needs a low barrier to entry. It can be trimmed later or plugins moved to seperate git repo's. I guess I'm a premature in wanting to thinking about this and my question would have been better phrased as "I have some aliases I want to port to fish, should I put them in custom or send a pull request for inclusion in the project".

As a talking point here are some common aliases I currently use in zsh:

# Shell
alias tmux="TERM=screen-256color-bce tmux"

# Ruby/Rails
alias rs="rspec spec"                                                           
alias cuke="cucumber features"                                                  
alias rr="rake routes"                                                          
alias rrg="rake routes | grep "                                                 
alias bi="bundle install"        
alias be="bundle exec"        

# Git
alias gb="git checkout -b"                                                      
alias gst="git status -sb"                          
alias gcl='git branch --merged | grep -v "\*" | xargs -n 1 git branch -d' # removes local merged branches                            
alias gpo="git pull origin"                                                     

# Browser
alias 8080="open http://localhost:8080"                                         
alias 8082="open http://localhost:8082"                                         
alias 3000="open http://localhost:3000"                                         
alias 9000="open http://localhost:9000"  

I think the tmux one is pretty specific and should not be included since it enforces configuration...

The browser alias ones are Mac specific, I guess the function would need to check for the existence of open and the equivalent(s) for Linux.

So what about the Git and Rails ones?

[bpinto]

As these aliases don't conflict with another function name, I think we can add these rails functions! :)

About git, I prefer adding alias to .gitconfig instead, but I think it's fine too. As we said, the worst scenario is to move any alias in the future from the repository to somewhere else.

[krisleech]

Thats one thing I thought about too, name conflicts, especially with one/two letter aliases.

.gitconfig versus shell alises seems to be personal preference, the general recommendation seems to be to use .gitignore (proberbly because it acts as a namespace), but I prefer no namespace because I don't have many aliases anyway.

Maybe I can send a few pull requests can we can discuss each indavidually.

Thanks for taking the time to discuss this.

[bpinto]

Sure!

On Fri, Mar 8, 2013 at 1:25 PM, Kris Leech notifications@github.com wrote:

Thats one thing I thought about too, name conflicts, especially with one/two letter aliases.

.gitconfig versus shell alises seems to be personal preference, the general recommendation seems to be to use .gitignore (proberbly because it acts as a namespace), but I prefer no namespace because I don't have many aliases anyway.

Maybe I can send a few pull requests can we can discuss each indavidually.

Thanks for taking the time to discuss this.

— Reply to this email directly or view it on GitHubhttps://github.com/bpinto/oh-my-fish/issues/18#issuecomment-14628636 .

Atenciosamente, Bruno Ferreira Pinto