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

Git autocompletion #4100

Closed
DragosDumitrache opened this issue Jun 28, 2015 · 16 comments
Closed

Git autocompletion #4100

DragosDumitrache opened this issue Jun 28, 2015 · 16 comments

Comments

@DragosDumitrache
Copy link

Ever since the last update, git autocompletion stopped working on tab.

It still works on other shells, but not on zsh. Since it's one of the features that I and I'm sure many others use constantly, it would be worth looking into, as it makes adding a large number of files painful.

@apjanke
Copy link
Contributor

apjanke commented Jun 28, 2015

Git autocompletion seems to be working okay for me, on OS X and Cygwin. What isn't working for you? Can you be more specific?

What OS and terminal are you using?

@alastaircoote
Copy link

I'm also seeing the following error with a theme that uses current_branch:

git_prompt_ahead:1: command not found: current_branch

I also tried using some of the aliases defined in the plugin but they don't work. Those for another plugin I use (npm) do work.

I'm on OSX 10.10.

@apjanke
Copy link
Contributor

apjanke commented Jun 29, 2015

Hmm. That's not good. Which theme is it that's using current_branch? And what plugins do you have in your list to load?

The current_branch() function is defined in the git plugin, not the core lib/git.zsh, so any theme using it will depend on the git plugin. This seems symptomatic of the git plugin not being loaded for some reason. There were several commits to the git plugin recently; maybe one of them is borking it for you.

Are you seeing any other errors or messages during your zsh startup sequence?

I pulled up 10.10.3 just now, with the latest OMZ update. Both current_branch() and some basic git completion tests worked for me, if I include git in my $plugins list. May be some configuration differences.

Could each of you post the output of omz_diagnostic_dump from here as a gist, so we can get some detailed debugging info to find out what's causing this?

@alastaircoote
Copy link

My plugins list is:

plugins=(git, osx, npm)

There's an issue to move current_branch() into core - #4085, which could be of interest. I'm not at the machine with the problem with now, but will send over the dump as soon as I can.

@apjanke
Copy link
Contributor

apjanke commented Jun 29, 2015

Yeah, check out who the author on that #4085 is. ;)

But you shouldn't need that: if $plugins contains git, then current_branch() should be available and you should be working.

Did you copy and paste your $plugins exactly?

plugins=(git, osx, npm)   # BUG

That will not work. In zsh array syntax, there are no commas between words: they will be interpreted as part of a word. So here, you'll have plugins named "git," and "osx," and "npm". When Oh-My-Zsh sees a plugin name it does not recognize, it silently ignores it. So it would look for "git," and find nothing and move on. If that is exactly your $plugins, then only npm will get loaded.

(IMHO that's probably a flaw in OMZ, and it should warn when it gets a request for a plugin that it doesn't recognize.)

The correct syntax for that plugins list is this.

plugins=(git osx npm)

@alastaircoote
Copy link

That worked! But to my knowledge I haven't altered my plugins list since I installed months ago, and that error message only appeared after a recent upgrade. So I'm not sure what's going on there.

But thanks anyway - back up and running now.

@apjanke
Copy link
Contributor

apjanke commented Jul 1, 2015

You're welcome!

Is it possible that that your $plugins was getting set in some custom OMZ files you have (under $ZSH_CUSTOM)? It used to be that custom files were loaded after plugins, but in #3617/#3809 (about a month ago), the load order was changed so that custom code is loaded before plugins are loaded. This allows them to alter the $plugins list, which was the intention. But it also means that if you used to have a good $plugins in your ~/.zshrc and a bogus one in your custom files, it would have worked before (because the bogus one got set after $plugins was used) and it would have broken a few weeks ago after an update (because now the plugin loading code saw the bogus one).

Upshot of this is that if you have custom code, you need to check how it interacts with your plugins. (See #4072 for how it affected some other users.)

@nyddogghr
Copy link

Hi, I'm not sure if this is the same issue, but since a few weeks the autocompletion in my shell stopped working too. I'm on archlinux, unsing ohmyzsh up to date. If I use git checkout <TAB>, it correctly displays the branch, but not with gco <TAB>.

Any idea on how I could solve it ? Same as for @alastaircoote it stopped working without me doing anything specific except update ohmyzsh.

Thanks

@apjanke
Copy link
Contributor

apjanke commented Jul 30, 2015

Could be. gco <TAB> completion is working for me with the current OMZ setup, so I don't think it's broken in the main OMZ code.

Check your $plugins value to make sure it does not have commas. If that's not it,
please run omz_diagnostic_dump from this diagnostics.zsh file and post the results as a gist. That'll give us the debugging info needed to track it down in your configuration.

@nyddogghr
Copy link

Hi,
I just checked and the $plugin value seems ok:
plugins=(git git-extras gitfast archlinux common-aliases chucknorris nyan systemd wd mvn sudo)
Here is the gist with diagnostics:
https://gist.github.com/nyddogghr/6b99d23355607b3fd33d
I also repulled oh-my-zsh from master to be sure. The only file not from the repo (as mentionned in the diagnostic file) is the diagnostic file.

@apjanke
Copy link
Contributor

apjanke commented Jul 30, 2015

Okay. I'm not sure what's causing this, but there are a couple issues there.

First, let's see if it's the alias itself or just the completion that's broken. What's your output for alias gco? It should be this.

$ which gco
gco: aliased to git checkout

Your ~/.zshrc file has sections which are redundant with Oh My Zsh. OMZ sets up completion with compinit, does terminal configuration, and so on. These sections, which run after OMZ, are redundant.

I don't think the second compinit call would be messing up your completion, but I guess it's possible.

You have a literal /other/things/in/path in your $path setting, from two different places. That sounds like some example code that was copied and pasted, and was supposed to stand in for other things in your path. It could be removed, unless you really have something installed there.

@DragosDumitrache
Copy link
Author

For some reason I've only now been notified of all these comments, sorry for the late reply. The problem seems to have been fixed as of two weeks ago, I'm not entirely sure what caused it, but after updating then, the tab autocompletion for git started working again. Initially, writing git add and pressing tab refused to suggest any files. Autocompletion worked fine in general, git was the only one having problems.

As for the plugins comma bug, I too had commas separating my plugins, but everything still worked before the time when I posted this.

To answer the initial question @apjanke, I'm using OS X Yosemite on the latest version and the default Terminal.

Here's the link to the gist dump, however, it might not be very useful:
https://gist.github.com/DragosDumitrache/d6e807e92cf3f5d62c14

@apjanke
Copy link
Contributor

apjanke commented Jul 30, 2015

Hmm. Might have been some of the work that was done on the git plugin and since changed, or might have been a broken zcompdump file, or something. Dunno.

If it's working now, want to just close this out, and reopen if it happens again? I don't see anything wrong completion-wise in the diagnostic dump, so I don't know that there's anything else we can do here.

Unrelated to git completion

A couple unrelated things:

You're doing a full reset of $PATH here.

# Default PATH
export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/texbin"

That's usually not ideal, because the system /etc/zshenv, which runs before your .zshrc, sets up the default $PATH, and picks up paths for installed programs. At the least, you should include :$PATH at the end of it, so additional paths supplied by the system are still included. Otherwise, programs which rely on /etc/paths.d to install correctly won't work. You also don't need to do the export each time; $PATH is already marked for export to the environment.

You might want to set $JAVA_HOME like this instead of with a hardcoded path, so you automatically pick up updates or changes to the main system JDK.

export JAVA_HOME=$(/usr/libexec/java_home)

I dig the starWars thing.

@nyddogghr
Copy link

$ which gco
gco: aliased to git checkout

This is what the command gives me, and gco branch indeed changes branch, so the alias is correct.
Also, you were right, something in my zshrc was overriding ohmyzsh : setopt completealiases
I've removed it and it now works. However I just don't understand why it stopped working suddenly ^^"
Thank you for your help

@apjanke
Copy link
Contributor

apjanke commented Jul 30, 2015

Ah, that was it.

From the zsh reference manual:

COMPLETE_ALIASES
Prevents aliases on the command line from being internally substituted before completion is attempted. The effect is to make the alias a distinct command for completion purposes.

I didn't know about this one. Good thing to look for in the future.

I bet I know why it broke for you: PR #2790 removed a bunch of explicit compdef statements for some of the aliases, including gco. Those compdef statements made the completion work even when complete_aliases is on. OMZ used to turn on complete_aliases, but in 8883ace turned it off, so the compdefs are no longer necessary for OMZ with the default configuration. See the discussion in #2790 for details. (I found this because I had a hunch there had been some change to gco completion in plugins/git, and just looked through its history log until I found a commit that had a relevant change.)

@mcornella
Copy link
Member

Please close the issue if everybody's ok now.

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

No branches or pull requests

5 participants