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

vim -c CommandT doesn't capture prompt properly #71

Closed
ascandella opened this issue Mar 28, 2014 · 9 comments
Closed

vim -c CommandT doesn't capture prompt properly #71

ascandella opened this issue Mar 28, 2014 · 9 comments

Comments

@ascandella
Copy link

I recently went through a recompile/upgrade of my OS X (10.9.2) workstation, and ran into a frustrating issue.

When I run vim -c CommandT (which is my default vim launcher, when no file is specified on the command line), I can type into the prompt and see my input reflected, but the match window does not update. When I Control-x out and :CommandT again, it works fine. I tried vim -c "sleep 100m | CommandT" out of desperation, with no change.

I tried both the official vim 7.4 tbz, and the mercurial head. I reset to previous versions of Command-T as well (my previous HEAD was 89896bd).

How do I got about debugging this issue? I'd love to help you fix it, but honestly I can't even tell if it's a vim bug or a command-t bug.

Thanks!
—Aiden

@wincent
Copy link
Owner

wincent commented Mar 28, 2014

I doubt it's a Command-T bug, but you never know.

My first instinct is to try doing this with an autocmd or some other such
hackery (instead of -c) to rule out -c as a confounding variable.

On Friday, March 28, 2014, Aiden Scandella notifications@github.com wrote:

I recently went through a recompile/upgrade of my OS X (10.9.2)
workstation, and ran into a frustrating issue.

When I run vim -c CommandT (which is my default vim launcher, when no
file is specified on the command line), I can type into the prompt and see
my input reflected, but the match window does not update. When I out and
:CommandT again, it works fine. I tried vim -c "sleep 100m | CommandT out
of desperation, with no change.

I tried both the official vim 7.4 tbz, and the mercurial head. I reset to
previous versions of Command-T as well (my previous HEAD was 89896bdhttps://github.com/wincent/Command-T/commit/89896bd
).

How do I got about debugging this issue? I'd love to help you fix it, but
honestly I can't even tell if it's a vim bug or a command-t bug.

Thanks!
—Aiden


Reply to this email directly or view it on GitHubhttps://github.com//issues/71
.

@ascandella
Copy link
Author

Same result on doing:

autocmd BufEnter * :CommandT

@wincent
Copy link
Owner

wincent commented Mar 28, 2014

I just tried this on my box (10.9.2, latest HEAD of Command-T next branch, Vim 7.4 with patches 1-161 installed via Homebrew, Ruby 2.0.0-p247) and it (vim -c CommandT) works for me.

Any other different stuff in your environment?

@ascandella
Copy link
Author

I've been building vim from source... I just tried to install the homebrew version and now I'm getting:

Vim: Caught deadly signal ABRT
Vim: Finished.

I'm guessing there's some mixing of libraries that I've installed from source and the homebrew version. I'll try to clean out my environment and get the homebrew vim running, since that seems more likely to work than my custom-compiled one (although everything was working fine before today).

@wincent
Copy link
Owner

wincent commented Mar 28, 2014

Yeah, just be sure to build Command-T with the exact same version of Ruby that your Vim links against. If in doubt, :ruby puts "#{RUBY_VERSION}-p#{RUBY_PATCHLEVEL}".

@wincent
Copy link
Owner

wincent commented Mar 28, 2014

I should also add, there is nothing special about the Homebrew Vim (I build Vim from source on my CentOS devserver and it works fine).

@ascandella
Copy link
Author

Aha... I got the homebrew vim running 7.4.161 and the -c behavior works again. I'm going to assume I just did something terrible when compiling my latest round and never try that again.

Thanks for the speedy responses! I was really worried I would have to live in a world where Command-T wasn't the first thing I saw when opening a new editor :)

@wincent
Copy link
Owner

wincent commented Mar 29, 2014

image

@ascandella
Copy link
Author

Hmm, so I did a little more digging today and discovered that the homebrew vim was a red herring. In the process of switching vim binaries, I had to disable the YouCompleteMe vim plugin (see above ABRT errors), which turns out to have been the problem. Re-enabling YouCompleteMe reintroduces the flaky launch behavior.

I worked around it by moving the call youcompleteme#Enable() from plugin/youcompleteme.vim augroup youcompletemeStart into the top-level, but it's mostly a hack.

Anyway, if you get future reports (or if you run into this issue yourself by installing YCM), this is a decent workaround (I imagine the impact to startup time is minimal given modern processing speed). I wish I knew enough about vim internals to debug this further, but alas, everything is working again.

Cheers,
Aiden

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

2 participants