Hacker News new | ask | show | jobs
by dontTango 2017 days ago
I'm interested in using vim, but I'm not thrilled about trying to set up debuggers when an IDE has it for you.

Maybe I'm over complicating it, anyone have a python based suggestion?

As a note, I do not have local admin but Vim is installed already.

11 comments

I often use a debugger (PDB++ or PuDB in Python) in my terminal, which I have open alongside Vim. But Vim historically has lacked strong IDE-like features, especially compared with Emacs.

This is starting to change with Neovim v0.5, currently only available on Git master building from source. But it's worth building from source, because it's a completely different text editor. Especially when you use a nice GUI frontend for it like Neovim-QT.

With the plugins nvim-lspconfig, nvim-treesitter, and nvim-dap, and plugin manager packer.nvim, you significantly close the gap between Neovim and Pycharm. I used to use Neovim for light duty programming and Pycharm for anything "serious", but with v0.5 and the plugins above (among others) I just use Neovim for everything.

The downside is that, because it's all very new and in alpha/beta state, the documentation isn't too thorough and things occasionally might break. But personally I haven't had any trouble with breakage, and the default plugin configurations do mostly what I want with only minimal fiddling. And if you're on Mac you don't even have to download a tarball and read the build instructions, just `brew install --head neovim`.

Neovim v0.5 is leaving Vim in the dust IMO. It's more like a Lua-powered LSP/DAP/Treesitter-based IDE engine than a text editor. Except it's also just a text editor and it still opens in less than 1 second.

IMO if you want an IDE use an IDE. There are a wealth of plugins that attempt more or less successfully to bring IDE-like features to VIM, but I'm not sure I see the point personally, it'll never be as seamless as an IDE built and maintained from the ground up to do these things. I hear that many IDEs have semi-competent Vim-style editing support, so maybe that would be more to your taste.

If you want to try the Vim experience I suggest doing it the Vim way, use a minimal config when starting, only add plugins after careful consideration, prefer simple generic tools like grep/rg, FZF, dumb completion and ctags over complicated tight integration with language servers and debuggers.

But maybe you prefer more integrated environments and that's perfectly fine, but in this case I wouldn't recommend a switch to Vim unless you have a very good reason to want it.

Without plugins Visual Studio Code in principle is just an editor. Yet even without any plugins or language-specific support it still a better tool for development out-of-the-box than Vim or Emacs. It can quick open and search across a development tree with thousands of files with no configuration.

So as an editor for config files and small projects Vim without plugins is OK. But that basic Vim experience just does not scale. One does need plugins with Vim for anything big.

I mentioned FZF (with Rg) with IMO is a great plugin to use. With it you can explore huge projects very quickly without requiring any language specific setup. Vim also supports tags files by default which can be quite nice when browsing large projects, just run universal ctags and you can cross reference symbols for most languages.

Actually the only project-oriented Vim plugins I use are FZF, editorconfig and fugitive (git interface). The rest are just editor tweaks such as vim-unimpaired and vim-surround. And I regularly deal with very large codebases such as the Linux kernel, so at least for my use case it scales reasonably well.

> Yet even without any plugins or language-specific support it still a better tool for development out-of-the-box than Vim or Emacs.

ⓘ This claim is disputed.

> It can quick open and search across a development tree with thousands of files with no configuration.

M-x find-grep would like a word.

Before you say anything, Visual Studio Code depends on (and bundles) ripgrep to do its fast searches. (Emacs defaults to using your system's grep.)

> It can quick open and search across a development tree with thousands of files with no configuration.

    git grep

?
Checkout chromium and try that on its tree. Or rgrep. Then try searching it with vscode and compare the timing especially with second and following searches. And vscode is smart enough to search files that where opened recently first bringing useful results instantly.
Of course if you need to cross reference the entirety of a gigaproject like Chromium you're going to need some sort of a cache and smart search. If I was a Chromium dev I'd probably set something up to help with that.

99.999% of source trees are a tiny fraction of that size however.

As I mentioned in another comment I routinely hack in the Linux kernel which contains about 15million SLOCs (per sloccount) and ripgrep takes less than 5s on a cold run and is near instant after that. ctags lookup almost instant regardless of cache. And that's on a 5 year old middle of the line SSD and CPU.

Inability to easily deal with chromium-sized repositories out of the box might be a deal breaker for you but it's a total non-issue for me.

> One does need plugins with Vim for anything big.

When a fresh shell tab is just a command-T/ctrl-T away, you don't need Vim to do any of these things in the first place. The point of Vim is that it's a text editor that lives in an environment where you can already accomplish everything other than text editing.

VSCode is a text editor that uses plugins to bring other programs into VSCode. Vim is a text editor plugin for an environment in which all those programs already run natively.

The problem with basic Vim is that it does not support out-of-the-box tools that can run longer than an invocation of a single command, like language servers, project indexers, tree synchronizers etc. ctags etc. just does not scale. And on Windows and to lesser extent on Mac one needs that even for medium-sized projects.
For Python vim is allright. The probability of making syntax errors is a lot lower than with languages like Java and you can see them without going through a build. But language servers are the only way to make vim an acceptable choice for a lot of other languages. Otherwise your productivity is just much lower than with an ide. Personally i use vim for terminal work, searching, merging, editing sql and other files, sometimes building and Eclipse for coding on my current project.
If you want to have it the other way around (having Vim inside your IDE instead of turning your Vim to an IDE) I’d suggest you to try IdeaVim [0] with PyCharm. Works very well, you can even use your own .vimrc file.

[0] - https://github.com/JetBrains/ideavim

Yes, that's what I'd recommend too.

Had a few days off and dived into my vim setup /plug-ins for python, but ended up with pycharm again. I could emulate most of pycharm (pros) features, but what made me end up going back to pycharm was the refactoring capabilities. Rope just didn't come close, while pycharm makes it trivial and rarely misses anything. Well that and having to manage all of these plug-ins on different OS/ python versions can become a time sink too. E.g. started out with vundle, but it did not support some of the features I needed to get an older commit of a plugin that was barely maintained anymore, so ended up rewriting the.vimrc with a different plugin manager... Etc etc

I use vim (neovim) for everything, but particularly for Python dev. The trio of Linux, tmux, and vim is a powerful combination for any language/framework IMO.

My workflow recently has been CoC.nvim (coc-python plug-in) which lets me integrate flake8/pylint for linting, jedi for completion, and black for auto formatting.

For me those three, linting, completion, format on save are the only IDE like behaviors I need. With Python3.6 or better, I can insert a breakpoint manually whenever I want.

I've been using vim for a bit over a decade now. But throughout that time I bounce between actual vim and vim emulation. Lately I've been concluding emulation is better most of the time.

The problem with real vim is maintaining your setup can be super painful. 95% of the time it's fine, but that 5% can really bite you. For example, this bug, https://github.com/tpope/vim-vinegar/issues/10, struck me out of nowhere. It was super annoying, and took some debugging and exploration to find a work around for. As you can see from the comments, it seemed to impact like 5 people, so you often don't have the advantage of a large audience pushing for fixes. In the end the bug was in vim itself, not the plugin btw.

With all that said, in my humble opinion I would say start learning real vim with say vimtutor (it is possibly already installed on your machine) and use vim to say edit config files or do git commits. When you are getting comfortable with the vim way of editing, switch to an emulator in your IDE. IdeaVim for the IntelliJ family is really good, that's what I use today.

If you're looking for an IDE I recommend Visual Studio. (Classic, not Code. Yes, on Windows.) It's awesome.
Why do you recommend Visual Studio Classic?
I'm not really sure how to summarize it but I guess you could say it's both powerful and intuitive.
I've been using an almost stock installation of spacevim both in gvim and terminal for the last couple years. It's sort of like a distro of vim plugins dialed in to play nicely together.
PyCharm + IdeaVim, the best Vimemulation i tried so far (VS, VSCode, Spacemacs). It supports Macros, you can use parts of your .vimrc and they ported several plugins, vim-surround and others.
I highly recommend trying out VSCodeVim. Use it for Go, JS, C, Rust and more - it's really enjoyable, and even stuff like C - W works just fine.
Unfortunately that plug-in is a horrible performance hit to an editor that already is on the slow side of typing responsiveness.
Seconding the suggestion for https://github.com/asvetliakov/vscode-neovim. Performance aside, it supports many more vim features and I believe it also plays better with undo.
The plugin called "Neo Vim" is much faster, although it requires a nightly neovim to be installed.
tmux + ipdb would be my alternative. I even use that approach within vscode.
Debug by print statement :)