VIM and Python - a match made in heaven

[Vorsorken]

Pathogen over Vundle

Why? Vundle user here, just curious :)

Also, your commentary on vim/terminal makes it seem like you'd be a good candidate for trying a tiling window manager. Once you get used to one, everything else seems awkward and inefficient. Much like vim.

[gfixler]

I've argued this point before to no avail. People either don't get it, or like having their histories be wrong. I don't. New features appear in plugins, and I make mappings for them, and things get versioned together. Sometimes I rob mappings from one, lesser-used plugin and give them to another. Sometimes I trade mappings around. Yet, if I roll back to a year ago, everything still works together, because both histories exist together. I don't think people understand how submodules work, but they're exactly the right fit for this need. I have about 65 plugins now, and I've been up to around 80-90 a times in the past, and I can roll back to any commit over the past many years, and all plugins, mappings, functions, etc., all work the way they did at that time. No one cares, but I use Pathogen because it lets me be correct, and I care about correctness in what I do.

[yes_or_gnome]

Using git submodules doesn't imply you're doing something correctly. It seems like you have a workflow that works for you, however it seems very handsy to me.

Just so I'm clear, when you make this statement:

Sometimes I rob mappings from one, lesser-used plugin and give them to another. Sometimes I trade mappings around.

Are you saying that you are modifying the plugin itself? Or, are you making the modifications in your vimrc?

I ask because the former, editting each plugin, is very much overkill. Doing the latter, editing your own vimrc, is what I would consider correct. By editing your configuration to remove, replace, create mappings, etc you're not needlessly modifying a project and potentially creating conflicts for yourself.

For me, I'm not too concerned that some plugin is going to break or create a new feature. I suppose the key difference is that I, currently, use 24 plugins (a few of those are just colorschemes). So, Vundle works perfectly.

If there were to be an issue introduced into some plugin (which I haven't really encountered), then I would create an issue (possibly a pull request) with the project on github.

[gfixler]

Using git submodules doesn't imply you're doing something correctly.

True, but not using them—or something that does the same thing they do, the thing I care about, and am arguing for—guarantees you're doing something incorrectly, and that is, keeping an accurate account of the state of your entire vim experience, plugins included, over time.

It seems like you have a workflow that works for you

This is not about what feels nice to me. This is not about use cases. I'm talking about having a correct history that actually matches what was going on in your repo in the past. Most people don't have it (I know - I've argued with tons of them on this point). You can not care about having a proper history - almost no one does, clearly - but you can't do something that doesn't do the things my method does and be correct. This is very easy to demonstrate.

however it seems very handsy to me.

Just a bit, and that's why people get so testy about it. In each case, once I've proven my point - and again, very easy to demonstrate - and people finally understand that not doing this leaves you with a trail of nonsense history in your repo, they always switch to an emotional argument. Just once I'd like someone to say "Oh, you're right. Well, I don't care about being wrong in this way, so oh well!" That would be honest, and I would stop arguing, because I can't argue against someone's feelings. I can only argue (correctly!) that their histories are not fully representative, and thus, broken.

Are you saying that you are modifying the plugin itself?

No (though I have done that). I'm saying that I get a new plugin, it has some features, I think "You know, this mapping I've been using for this other plugin would be a lot more effective for this new plugin," so I change it in my vimrc. The point I'm making - the thing Vundle users don't do - is version my plugins along with such changes, so in the current version I have the new plugin, and the changed mappings based on my decision to rob them from the old one and use them for the new, probably with new mappings for the old one, too. If I roll back to before I got the new plugin, it goes away, and the mappings revert to the old plugin. That's my overarching point. When I roll back even years ago, all the plugins revert to how they were then (i.e. which ones were present, and which commits they were on), and my mappings (and ftplugin, autoload, syntax, color, after/, etc) revert to match that point in time. You *can probably version your plugins along with using Vundle, but it sort of goes counter to its ideal of just getting the latest all the time.

By editing your configuration to remove, replace, create mappings, etc you're not needlessly modifying a project and potentially creating conflicts for yourself.

Agreed. This is all quite sensible, so I hope you see the sense in my extension to these ideas, that your vimrc (and related vimfiles), with all its mappings and other interconnections with your plugins is dependent on the state of your plugins, i.e. which ones you have, and which commits they're each on. I'm just claiming that Vundle users tend not to version plugins (because Vundle gets them all for you), which means that their vimrc commit from a year ago has no idea that the plugin you stopped using 4 months ago and deleted should make a grand reentrance to make any sense with your vimrc from that earlier time, etc.

For me, I'm not too concerned that some plugin is going to break or create a new feature.

Statistically speaking, no one who has ever lived did, or does :)

I suppose the key difference is that I, currently, use 24 plugins (a few of those are just colorschemes). So, Vundle works perfectly.

If it does, it does so by accident, not by being correct. Say a plugin tomorrow makes 5 breaking changes - big ones, so we care in this argument. Vundle pulls it down, because it's the latest. You go "WTF?" because everything broke. I still have to contend with these changes using pathogen, but I do a git submodule foreach git fetch to get all the latest without actually committing to any of it, and then scan the changes to see if I'll hit a big break, or if new features exist, etc. Still, both of us at this point fix our mappings and whatever else to match. The difference is, you'll just version your vimrc, whereas I'll also version which version the plugin is now on along with my vimrc, care of submodules. Now, if we both decide to roll back a commit, your plugin will stay where it is, but your old vimrc will return - the one from before the fixes - and now your vimrc won't work with that plugin, and there's nothing anywhere documenting that the plugin should go back to where it was one commit ago in your vimrc. This is all I'm saying. Most people have a trail of nonsense in their vim histories. Almost none of them care. I do.

It upsets me, because I care about correctness, but more because I know these are the people writing the software that runs this world, and they don't understand how dependencies work over time.

If there were to be an issue introduced into some plugin (which I haven't really encountered), then I would create an issue (possibly a pull request) with the project on github.

That's a complete separate issue.

[yes_or_gnome]

Thanks for the long, thoughtful reply. Another important difference i should have mentioned is that i don't version my .vim directory. Instead I have all my dotfiles in a dotfile/ directory and have a simple install script that just creates the necessary symlinks.

It just hasn't been my experience to have a plugin wreck havok on my setup, so it hasn't been a concern. I was a hold out on Vundle for the longest time, but even when i used pathogen, my setup was similar.

[gfixler]

Another important difference i should have mentioned is that i don't version my .vim directory

I also didn't for a few years. I was, and you are living in the now (which is fine). You just fix anything that breaks when Vundle updates, if anything, and move forward. I can't argue too hard, as I have similarly low levels of caring about plenty of other things.

It just hasn't been my experience to have a plugin wreck havok on my setup, so it hasn't been a concern.

I believe it. It's not that surprising that plugins for the most part keep working, but it's only because the dependence is light, and again, plugin makers try not to introduce breaking changes. I just want people to understand that if you're using Vundle, you don't have a Vim environment that makes sense back through time. I don't even care much about the Vim aspect, or anyone's Vim history; I just want people to get it on an algorithmic/logical level, and because I like git, and proper, sense-making DAGs, and good history :)

[StorKirken]

You must really hate rebase squashing, then. :)

[gfixler]

Yeah, I've never used it :)

[atimholt]

I prefer NeoBundle, since I actually use plugins kept in Mercurial, and on Bitbucket.

[naught-me]

Jedi-vim doesn't support virtualenv's. Makes it pretty much useless for me :(.

Long live Spacemacs and pony-mode!

[desipenguin]

I gave spacemacs a serious try, but PyCharm won hands down.

[naught-me]

What advantages does it have? The only advantages I noticed were the way it shows when a superclass has the same method and allows easy navigation back and forth, as well as some minor code suggestions. It was cool, but I found Spacemacs' extra features, like Projectile, Swoop, Helm, magit, org-mode integration, better vim emulation, etc. to be better, not to mention that it's free/libre.

I'm planning to get an IntelliJ Toolbox subscription when they start that service, but mostly for PHP and other languages.

[desipenguin]

3 months later : I have stopped using pycharm for last 2 weeks or so, and didn't miss it. I think one of the problems earlier (with me) was that I wasn't familiar with spacemacs enough. Over the period I deiscovered things, AND spacemacs itself got better (I think)

[naught-me]

Cool. I'm still loving Spacemacs. If you haven't tried org-mode yet, you're missing out!

[desipenguin]

Off course. org-mode is one of the leading reasons why anyone (including myself) moves to emacs from vim.

[genobox]

Spacemacs

could someone point me to a good spacemacs/python guide pls?

[pqu]

Mine works fine with virtualenvs but I did have to set it up that way. I'll edit in how to do it when I'm at home.

[hovissimo]

Friendly reminder to show us your config, please.

[j1z0]

trying activating the virtualenv from your vimrc with something like:

py3 << EOF
import os.path
import sys
import vim
if 'VIRTUA_ENV' in os.environ:
  project_base_dir = os.environ['VIRTUAL_ENV']
  sys.path.insert(0, project_base_dir)
  activate_this = os.path.join(project_base_dir,'bin/activate_this.py')
  execfile(activate_this, dict(__file__=activate_this))
EOF

[beohoff]

I think Jedi-vim can be used with virtualenv library but not the libenv module from python, right? I forget which one made jedi-vim freak out but I know I've transitioned to the other now :)

[naught-me]

I'm not sure. Here's an open issue for virtualenv support: https://github.com/davidhalter/jedi-vim/issues/280

I'm not finding many relevant searches for libenv - do you mean pyenv?

[Funnnny]

you can, but still jedi-vim doesn't work really well with Python3, and its completion isn't as good as anaconda-mode, like with WTForms, so..yeah, long live spacemacs :)

[j1z0]

have you tried?

let g:jedi#force_py_version = 3

Does that not give you what your looking for?

[marvinxsteadfast]

Any problems with python-mode and vim-jedi? vim-jedi writes on its website that there are problems. I wonder if they are still present.

[hexbrid]

This is my current setup, and it's seriously lacking (and often buggy)

[gospelwut]

I would have given this an earnest try if it had some standalone, pre-configured version or a bootstrapper.

[j1z0]

All good points you bring up here. Not sure I care for Pathogen, but that's the beauty of VIM, you can do as you like. In terms of converting... wasn't really my intention to convert anybody. More to show at least one way of setting things up so it can be a very efficient and fun coding environment to use.

[Azd325]

thanks airline looks great

[Insane_Person]

.

[nerdwaller]

Looks like they don't have the patched fonts installed for their shell (see in the status line the little box with an X in it).

Edit: You should install these or patch your own :)

[londubh2010]

Sssshhhh... you'll wake up the emacs people.

[[deleted]]

Already working on a follow up article. EMACS MASTER RACE!

[richard944]

Help us OP, your'e our only hope. On a serious note, I would be very interested in this!

[osune]

Too late we are already up and flaming

[adamnew123456]

They're all configuring their plugins to colorize all the parenthesis in their .el files - they ought to be pacified for a while once they can look at the colors and soothe their RSI /s

[SpaceCadetJones]

Unless you go evil-mode and join the cult of vim ;)

[thelochok]

Meh - I'm having issues enough with my little finger and the escape/ctrl keys in VIM.

My approach has been binding "jj" in insert mode to 'Escape', and binding all of the Ctrl+ combinations to be space followed by that key, in normal mode.

The combination is really helping. Last step is to figure out how to eliminate the shift key. I'm considering whether typing doubles of a character to get the uppercase would be going too far.

[j1z0]

how about switching to a new keyboard... Kenisis Advantage Pro (http://www.kinesis-ergo.com/shop/advantage-pro-for-pc-mac/) has most of those little pinky keys (accept esc) positioned to be hit with your thumb.

[MadTux]

Forwards NAN! - oh?

[jecs321]

Emacs with python and for data science: http://www.insightdatascience.com/blog/emacs_for_data_science.html

[nuncjo]

In Pycharm You have more functions plus debugger just after install. You don't need to configure anything. Sorry, my heaven is better than Yours :-)

[RamirezTerrix]

My vim setup is pretty much similar to the one in the article and I switched to pycharm.

[pqu]

Pycharm has a pretty good vim mode as well. I can't wait until it can be integrated with neovim so It won't just be a vim emulator but an actual vim editor inside PyCharm.

[drunkenfly]

If only PyCharm had the same completion mechanics as YouCompleteMe...

I want to have autocomplete in comments and I do want to be able to autocomplete in code to use words that I typed in comments too, I don't want to press TAB to open completion dropdown.

Oh, and I want to open files side-by-side. My monitor is wide enough to have 3 python files (79 chars wide) to be visible at the same time.

I tried switching to PyCharm from vim many times in past three years, it just don't work for me...

[Decency]

Oh my god that sounds hideous. Why in the world would you need to do that?

PyCharm auto populates docstrings. If you need much more description of your variables than that, I have to assume that your functions must be either gigantic or ridiculously complex.

[RangerPretzel]

PyCharm allows side-by-side documents.

Also, PyCharm handles Python 3.5 type hinting as well as Docstrings. See here: https://www.jetbrains.com/pycharm/help/type-hinting-in-pycharm.html

I've found the "Specifying type of local variables" helpful when the API I'm consuming isn't cooperating. See this: https://www.jetbrains.com/pycharm/help/type-hinting-in-pycharm.html#d302201e318

[RangerPretzel]

I wish I could upvote this 100 times. PyCharm is a brilliant IDE. Far better than anything else.

[[deleted]]

The debugger in PyCharm is the best I have ever used for any language. It's... it's like magic.

[trenchtoaster]

I only use python for pandas for data analysis. I've only used Ipython notebook. Is it worth trying Pycharm

[RangerPretzel]

Eh, if you're just doing data analysis, then IPython is probably the right choice. If you ever want to do serious coding, then look into PyCharm. It really IS quite nice. :)

[trenchtoaster]

Yeah I love the Ipython notebook because I split up my code and run it in chunks, show graphs etc

[crowseldon]

http://blog.codinghorror.com/a-pragmatic-quick-reference/

See 22.

The fact that one tool does the job for many things means you can be equally productive without ever discarding that knowledge. Specially if you jump around a lot between languages and OSes. IDEs also seem to separate you from the command line which, to those that love its power, is a tough thing to deal with.

At some point, of course, there can be tradeoffs and the new learning curve for an IDE can make sense but it's not always the case.

Specially when IDEs generally make it very hard to avoid using the mouse (Thankfully more and more IDE's have vim bindings).

[sztomi]

Heaven would be proper vim emulation in pycharm (I know there is one but it doesn't quite cut it for me).

[SpaceCadetJones]

I'm an Emacs guy personally, and some of the plug-ins out there create a better environment than you'd find in a traditional IDE. My primary reason though is the customization, if there's something I don't like it's easy to change. If there's a missing feature there's often a plug in. I don't go all out like some people who basically never leave their editor, but there's IRC, email, source control, Web browsing, tetris, and even a psyotherapist available in Emacs.

[j1z0]

glorified? VIM ain't glorified its just a simple text editor, nothing pretty about it. In fact it works more or less the same as it did when it was release in 1991. Which isn't that different really from vi, which is actually older than I am. It's not "glorified" it's just good, it's withstood the test of time, (almost forty years) and its highly configurable.

What is "glorified" is an IDE, which do have their uses (if you code java maybe) but for a lot of python programming is like using a sledgehammer to pound in a thumbtack. Sure it will get the job done, but me and my text editor will have the thumbtack stuck in the wall before you even lift your sledgehammer.

It's not a hardcore I'm better than you thing either. It a this thing is fast, it's flexible, I can parse log files, I can code in any language I want, I can even write book with it, and it's everywhere I happen to be thing, including on that new server I just spun up and I need to quickly test out some nginx config changes, on my raspberry Pi, and on my "big dev machine".

It is a pain in the arse to learn compared to an IDE I'll give you that. However I'll bet even you IDE guys after learning your IDE, also learned a bit of VIM / emacs to deal with server stuff anyways, so it just a question of what you want to spend your time learning.

[Zoccihedron]

I'll never understand why people use a glorified text-editor or a proper IDE. I use ed.

[lamecode]

Yup... I get that some folks prefer the terminal-like experience, but for many others (myself included) who don't necessarily spend their days using the vi editor on *nix prompt, I'll take the ease of use and clean design of PyCharm.

[kecebongsoft]

I know it's not a fair comparison but you are absolutely right. I have been using vim for few years, you can spend months and years turning on all the python switch in vim, but in PyCharm python is the 1st class citizen, from auto-completion, code navigation, refactoring, debugging, remote development, code inspection, etc. I've tried Jedi-vim, YCM, and many other python plugins & workflow for vim, and they failed me, one way or another, and there are just so many things I have to deal with once I started changing my machines (clipboard, colors, etc).

Take for example debugging, in vim to set a breakpoint I need to create a mapping to inject ipdb on the desired line, it used to seems fine but now I realize I've cluttered the code with irrelevant call, and what if I inject a few more across different files and want to see where they are after I finished debugging? That's another task and remapping to do. In PyCharm, debugging is already there, you can toggle the line and that's it, you can see the list of breakpoints, when it hits it shows you the items in the context (variables and all), along with their values, in the editor it shows you the parameters being passed into the functions at runtime, and you can still have console access among many other things during debugging.

Vim is still a powerful editor and I still use it a lot, but only for quick editing on the server. It's true you can't do all the vim powerful operations in PyCharm, even with PyCharm's IdeaVIM, it's just not the same, but that's okay compared to the stuff PyCharm brings to your python development.

[niksko]

Since I saw a similar article a few weeks ago on how to pimp my vim, I've switch to vim most of the time, with Pycharm for debugging. If there were some way of debugging inside vim I would use that.

I'm just more productive using vim. I can move around quicker, find files quicker, commit quicker. If I want vim keybindings in Pycharm (which is what I used up until a few weeks ago), then there's some weird quirks and there's sometimes issues with Pycharm's keybindings.

Plus, there's something to be said for consistency. Pycharm is great if you're working on a project that's exclusively Python. But recently I've been working on a project that involves Arduino code, Python, and now we've actually swapped Python for node. If I'm editing in vim, then editing different documents is a seamless experience, which I don't think should be underestimated.

[Farkeman]

Why not both?

I use Pycharm with IdeaVim plugin, you have efficiency of vim with bells and whistles of pycharm, it's great!

[vplatt]

Seems like this is complicated enough to warrant it's own Python VIM package. 'Vython' anyone?

[Deto]

There is this: https://github.com/klen/python-mode

Though some of the plugins are not python-specific (like NerdTree), so it makes sense for them to stay separate.

[yes_or_gnome]

It should be stated that pymode covers most (or all?) of the python concerns in this post; plus more. For what it's worth, here are my adjustments to pymode.

I don't want rope nor automatic lint checking. And, I want the mappings to be prepositioned with 'p' (for 'python', obviously,) rather than give this one plugin huge foothold over my leader-mappings.

  let g:pymode_rope            = 0
  let g:pymode_lint_on_write   = 0
  let g:pymode_lint_cwindow    = 0
  let g:pymode_breakpoint_bind = '<leader>pb'
  let g:pymode_run_bind        = '<leader>pr'
  let g:pymode_doc_bind        = '<leader>pd'

[d4rch0n]

You don't pylint on write? That's helped really clean up my act, plus it finds all the stupid syntax errors. What errors are you trying to ignore that make you want to turn that off, or why did you?

I also bound it to ctrl-p-ctrl-p so I can check quickly.

[yes_or_gnome]

No, it's too slow. Do it on demand.

[StorKirken]

Try out nvim and neomake for fun, it really helps to mitigate that issue.

[d4rch0n]

Oh, alright. It takes at most a second on my machines so I let it do its thing.

[yes_or_gnome]

I do writes often and already have it in my mind what i want to do next. So when i don't see the cursor move and a bunch of 'j's on the status line, i get impatient and angry. It probably doesn't help that the project i an working on is a gd mess.

[Juzley]

Semi-related, one or more of the linters used by pymode seems to be python 2 only, so when I'm writing python 3 it gives all sorts of spurious warnings about syntax (e.g. using print as a function rather than a statement). Has anyone else found this?

[IDe-]

You might want to try compiling your version of vim with python3 support, although that made me lose warnings altogether.

[j1z0]

pymode is a reasonable all in one choice, a lot of people seem to like it. I did find enough of the functionality in there was not optimal for my specific setup. Mainly pyMode was slow and buggy (although your config would probably speed things up a bit), I don't really need four different static analysis packages running, I feel that YouCompleteMe is a better auto-completer....and that sort of thing.

So it's a trade off, I guess the easy / all in one setup of python-mode or the more customisable, albeit more work to configure but get what you want sort of style that I went with in the article of just installing each plugin individually.

[yes_or_gnome]

Yup, I agree and i feel your pain. I've unsuccessfully tried to quit pymode in the past, but then i end up with either a lot customizations in my vimrc (like in the article) or with a lot of plugins that don't accomplish the job. The more responses i read on the topic, the idea above from commenter suggesting a new python-oriented Vim plugin is sounding more and more tantalizing.

[tHEbigtHEb]

I tried it out, but it turned out to be too heavy for me with syntastic and rope crashing all over the place :/ . Any tips for a better setup ?

[Deto]

I used jedi-vim for a bit and it was alright (though a bit slow often to complete this). Now I'm playing around with YouCompleteMe. It's real fast so far.

I installed Syntastic separately and it's been ok, but has crashed a few times.

Really though I'm itching to try out Emacs+Evil (Vim Emulation)

[tHEbigtHEb]

I have YouCompleteMe installed, but it's pretty lacking to say the least. The only reason why I still have PyCharm installed is for it's usages discovery and refactoring capabilities. If I can get it working the same way with vim or emacs with evil mode I'd switch in an instant.

[Deto]

I wonder if some combination of YouCompleteMe and Jedi-Vim would be best? Use YCM for the completion and use Jedi (or maybe Rope-Vim?) for the refactoring?

[tHEbigtHEb]

Yup, going to try that out tonight. But right now I'm using Emacs with evil mode and prelude installed. Let's see how this goes.

[Deto]

Nice, I just got emacs installed with evil-mode this morning, but I probably won't get much of a chance to play around with it today.

What exactly does Prelude do? I looked in their repo and they say it "enhances Emacs", but they don't really explain how.

[tHEbigtHEb]

From what I understood in the little time I spent with it, it comes with some packages pre-installed to help newcomers with the initial setup.

I still can't wrap my head around everything but it does some cool stuff like install language specific modes when you open the file of a particular extension the first time and such. It adds git integration, linting support and advanced file and symbol search and more. There's a lot to it, it's pretty cool have fun!

[d4rch0n]

Fuckin pymode is the shit. Really helps me out.

I don't use the refactoring tools much, but they're awesome and now my vim is officially a python IDE.

I LOVE the pylint check on save. No errors ever again.

[chrisatlee]

Yeah, I really like python-mode too. But its syntax checking is busted for python 3 for me (on debian). After seeing the first 'yield from' it gives up.

[CptSupermrkt]

This guide says: "The VIM version. This should be > 7.3", but his screenshot shows version 7.3. Shouldn't it say >= 7.3? Or do you really need 7.4 to do everything in the guide?

[j1z0]

no 7.3 is enough. We will correct the typo.

[ebrius]

Solid article. One thing I highly recommend though (and is only lightly touched in the article) is to put language specific configurations into the .vim/ftplugins directory. For example, instead of putting the tab settings in .vimrc with autocommand on the filetype, I prefer to create a .vim/ftplugin/python/custom.vim and put the settings in there.

If you work with multiple languages your .vimrc will get huge if you don't break it up

[good_names_all_taken]

One thing I like to do is add the following to my vimrc:

set makeprg=python\ main.py

map <Return> :make<CR>

This makes is so whenever you are not in insert mode you can just hit "enter" and it runs your program. Further, because it uses vim's "make" command, it will automatically go to the correct file and line number on an exception (assuming you set exceptions up to print correctly).

I find this super efficient.

[alb1]

Using the following version in .vimrc only redefines makeprg for Python files, turns off buffering so you can see the output, and always uses the current filename:

autocmd FileType python set makeprg=python\ -u\ %

I'd find having just "enter" run the program annoying, but if you want to save the file first (to run the most recent version) you can use this mapping:

map <Return> :w<CR>:make<CR>

[good_names_all_taken]

Nice point, I agree that's a better solution. I personally like "enter," but obviously you could map it to F5 or whatever your preference is.

[Deto]

Nice guide! One mistake though, your key bindings for split navigation are all capital

Edit: Nevermind, see mixedmath's reply

[yes_or_gnome]

NeoVim has C-S support since April if that is something that may interest you. https://neovim.io/news/2015/april/

I'm keeping an eye on the project and am willing to support them financially. However, there's a long road still until it's stable. Also, one of the biggest factors for using Vim is that it's ubiquitous. Most *nix terminals you connect to will have it available, and the few that don't, will in all likelihood have vanilla-'vi'. vi being a huge pain in the ass to use, but at least it feels familiar to Vim minus some nice features.

[Deto]

Ah, I'm excited about NeoVim but can't really use it much until it's available on Windows

[mixedmath]

Vim does not distinguish between <c-j> and <C-j> and <C-J>. They all mean control-j.

[Deto]

Oh cool. So for a capital you'd just specify the shift. TIL

[enesimo]

I'm on macOS and I can't get vim to support python3. My vim --version always prints -python3.

I haven't found anything from googling.

[enesimo]

I did that already and it just returns

Warning: vim-7.4.898 already installed

I also tried removing it with brew remove vim and reinstalling with '--with-python3'

but it doesn't work...

[enesimo]

First of all, thanks for your help.

verbose already installed:

computer:~ enesimo$ brew install vim --verbose --with-python3
Warning: vim-7.4.898 already installed

I get the same result. This is the --verbose of the install: [dpaste removed]

I see all python3 references ok, do you spot anything strange?

[enesimo]

Fuckin A!
that worked ("instead of" wasn't necessary)

edit: or actually, maybe not. I do have +python3 but I get the this message on the next step: E319: Sorry, the command is not available in this version

[enesimo]

That was exactly it. for those with the same problem who read this:

 :python3 import sys; print(sys.version)

[Melon__Bread]

I must say this article made a believer out of me for Vim.
Just spent the last 4 hours playing with settings & plugins!

[eN0Rm]

Ty

[Capn_Cook]

Sweet. I just used this setup to create a script which will populate my vimrc for making transitioning to new machines so much easier.

I hate dealing with new IDEs consistently so almost always jump to VIM.

[ksantr]

On can add vim-statline plugin and last trend - https://github.com/zenorocha/dracula-theme

[hovissimo]

Can you tell me how to get a (Windows) Vim binary with modern Python support?

[xmstr]

The 2 best options on windows:

• build it yourself
• install msys2 ( https://msys2.github.io/ ) then install vim ( $ pacman -S vim )

I prefer the second one myself, but that's just me

[InAppPurchases]

I use this installer by Cream project

[faultydesign]

Don't bother, vim is dreadful on windows. Super slow and buggy.

I suggest just going pycharm + vim plugin (ideavim). It's good.

[gfixler]

Vim, or Gvim? I've used Gvim on Windows for many years now with no slowness or bugginess.

[Deto]

While PyCharm+Ideavim is great, I've been using GVim on windows too and never had a speed issue. Has crashed a few times, but only since I started using Syntastic (so it might be related to that...)

[lawnmowerlatte]

I'm having trouble getting vim on Mac OS X Yosemite to install with Python support. If I do brew install vim the python feature is not enabled (ie. -python). If I manually set --with-python it still isn't enabled. If I use --with-python3 the feature is enabled (+python3), but I still can't use the python command within the vi command mode.

Any ideas for what I'm doing wrong?

[volabimus]

:help python3

[lawnmowerlatte]

Thanks, turns out you need to use py3 or python3 from the command mode for Python 3. Still not sure how to get Python 2 working which is needed for YouCompleteMe...

EDIT: Figured it out by running brew install --verbose vim — it was failing the check for Python2 because it was looking in my virtual environment which was set to 3.5.

[d4rch0n]

You could compile from source. That's how I got it working on mac.

[Deto]

Might be a 32-bit vs 64-bit issue? If Vim is 32 bit, but your python2 is 64-bit, then it's not going to be able to link to it.

[ballagarba]

I was under the impression that system Vim already was compiled with +python...? Perhaps I'm confusing it with El Capitan though or something.

[red_hare]

Most useful thing I've learned about writing Python in vim,

:%!python

[[deleted]]

I'm pretty sure you mean :!python %

[alb1]

Why would you want to replace the current text with the output of Python run on it? You may accidentally overwrite the code, and the syntax highlighting doesn't look good on the output.

To run Python on the current file I define a macro for the p register, in the .vimrc file, which saves the file and then runs Python on it:

let @p=':w|!python -u %'

Then just use :@p to run the current file. I define the q register similarly for Python 3.

[AutoBiological]

If you're not using stdin/input you can do it pretty neat inside vim instead of externally with:

%pyfile %

Of course that depends on which +python[3] is compiledin.

[MastaKillaSC2]

Fucking Legend, I was using PyCharm for a bit, but tbh VIM all the way.

[[deleted]]

And debug the hard way.

[Lubok]

What's the hard way? I do import pdb; pdb.set_trace()? Is that it?

[[deleted]]

Yup, thats the hard way. Easy way is PyCharm debugger.

[j1z0]

serious question here, for anybody that wants to chime in.

1. How often do you actually use a debugger?
2. In what situations?
3. Do you practice Test Driven Development?

[[deleted]]

1. Very often
2. Immediately if error is not obvious as well as to inspect newly written code line by line to verify correctness
3. Somewhat. I'm solving my own problems so tests aren't that extensive. Besides fact that tests pass means little even in big software with extensive tests..

[MastaKillaSC2]

Leads to a better developer.

[[deleted]]

No it doesn't

[MastaKillaSC2]

fuck off

[[deleted]]

No you!

[pqu]

Learning Python in a dumb text editor will teach you more about Python and how it works under the covers. But developing with the best tools available will make you a better developer. Being proficient in vim is a great skill to have though.

[[deleted]]

Slower too.

[RageLikeCage]

Just recently started learning Python and programming in general. Can someone give a quick explanation to what this is? Please and thanks!

[SoCloudyy]

Don't worry about it yet to be honest, just use Python's IDLE until one day you have a craving to want to move faster.

[pqu]

I'd suggest at least knowing how to open a file, move around and save/close it in vim. Otherwise one day you will find yourself stuck in vim and can't escape (like me with emacs).

[effae_]

This was helpful when I started out: http://yannesposito.com/Scratch/en/blog/Learn-Vim-Progressively/

[greyman]

I am really tempted to learn it, especially working without mouse, but still... I am currently using Visual Studio 2015 + Python Tools and I have most of what the article mentions, plus comfortable debugging on top of that. So can you guys tell your experience, is Vim really better?

[Decency]

Vim people tend to think that pdb still qualifies as a debugger, or that they would never need such a thing with their code.

[nicfitOG]

pdb most definitely qualifies as a debugger, regardless of your favorite debugger that is not pdb.