< a quantity that can be divided into another a whole number of time />

VS Code and Python

April 8, 2019

I tried VS Code during a few days for Python development. It looks like folks at Microsoft did a really great job at integrating so nicely Python into this IDE, which itself has greatly improved over time.

What’s up with Emacs or Spacemacs? I have been using the LSP mode for dealing with projects. It works effectively, but I sometimes find it not as responsive as I would like it. Not that I am working on big projects mot of the day, quite the opposite (a few dozens of files generally), but depending on MELPA updates, I’m facing unstable or unresponsive behavior from time to time. So I decided on Thursady to give another try to VS Code, after having stopped using Atom a few months ago. That we need 800 Mo of RAM for a text editor in idle mode is a lot more than I can tolerate for my MacBook; plus there’s no way to get a terminal for real, and I think I have gone through all Bodil Stoke‘s proposals before I realized that configuring an editor using JS is just a crazy thing. Still, I love the design and look’n feel of Atom, and I miss the Hydrogen package.

This is not the first time I try VS Code. Last one was two years ago, after I watched one of Swizec Teller‘s live code, but at that time it looks to me that it was still in early infancy, more focused on Node/JS devs and that there was not such attractive support for C or Python. The only component that was really baffling to me was the integration of Git. Those little markers in the left margin were kind of a beauty, especially given the fact they were also interactive. Surely we can have those pretty markers in the Emacs gutter, but it is more appealing visually in VS Code, and you get access to revert/commit of any chunk in a few clicks. There are other packages to deal with Git history or interacting with Github, but if you are only interested in tracking changes as you type, this is the best software add-on I ever found in an editor.

If you are happy with working using plain text Python files, I believe that the MS python package is a great choice. You don’t even need to install Anaconda–I’m using the latest homebrewed version of Python on my Mac, and it is works right out of the box. There’s a beginning of support for working with Jupyter notebook as well, but nothing close to what was available in Hydrogen under Atom. The autocomplete and intellisense features are gorgeous; You also get refactoring and linting for free. The built-in support for automatic indentation is good, although I managed to get into a situation where VS code was lost following an extra space in front of a def statement. Anyway, this is a really good package, which comes quite handy to navigate quickly between definitions and references, or access documentation on the fly. Just over a method and you get a nicely formatted popup window with all the details. Here’s a little preview to give you an idea:

As of today, I remain certain that it is impossible to switch my daily work entirely to VS Code, and I’m quite mitigated about the future of this editor since the integration of external projects remain subject to the capacities offered by VS Code itself. It also lacks support for Org mode (the existing package only provides syntax highlighting plus a few commands related to org-todo items, but nothing close to org-ref or babel), and I don’t feel comfortable at all editing Markdown text. I remember I had the same feeling the first time I tried VS Code. The Stata package is quite good, but the R package is far less capable than ESS under Emacs. Moreover, the lack of consistent keyboard shortcuts for sending line or selection to the integrated Terminal in R or Python (or the Stata GUI when using Stata package) is a real shame. I miss the default keybindings of Emacs, and its flexibility to remap any command to any combination of shortcuts or chords. Note that it seems that it is possible to define custom key chords in VS Code.

Another critical aspect of VS Code is the fact that it is project-oriented, meaning that it is hard to work on multiple files if they are not all in the same folder (note that the definition of a project goes beyond a git-based folder). On the one hand, this is good practice since it forces you to work on only one project at a time; on the other hand, it becomes hard to open another file for quick fix or to add a short note, unless you are willing to have many VSC editors opened on your desktop. Anyway, let’s see how it goes with my Python projects as a backup solution. What’s for sure is that sooner or later I’ll come back to Emacs full-time for writing Python code, and I’m not about to leave Emacs for good, if only for the org and racket modes, as well as Eshell and Magit.

python emacs

See Also

» Emacs and Python 3 » Emacs auto-completion for Python » On getting into richer data structures » Processing large CSV files » Org-mode and blogging