`vim -c CommandT` doesn't capture prompt properly about command-t

[wincent]

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 [email protected] 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]

Same result on doing:

autocmd BufEnter * :CommandT

[wincent]

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]

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]

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]

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]

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]

[ascandella]

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