[Return to blog] [Home]

VIM’ization of my workflows: A new learning experience

A few weeks ago, i finished my second semester of grad school, which puts me in a place where i look up for new resources to learn, some hobbies to practice and whatsoever cs, art-related stuff. While looking for ways to customize the way i type and edit my various sorts of code, text, etc, i stumbled upon VIM, the editor.

When facing new information to consume and learn, i float around the spectrum of getting somehow excited and at the same time overwhelmed of the amount of information i will need to process. I remember using vi / vim in college, while browsing around scripts and edits in the CentOS machines on the microelectronics lab. Back in the years 2016-2017, the usage of this editors was extremely casual and somehow ended in me trying to open the file in gedit instead of using vi/nano or any modal editor. In fact, before getting to known vim, the whole concept of modal editor was kind of cloudy.

So, as part of a 2022 new year resolution to get out there and try new stuff (programming related), i proceeded to install vim/neovim and test it out myself.

Plugins

Believe when i say the learning curve overall for me was hard. Not only hard, but a bit discouraging at times. After what felt like days of switching back and ford from vscode to vim and vscode again and google colab (I do data science myself) and vim again, i found No More Tech! guide on neovim Installation and Configuration, and it felt like a glove at hand. It helped me setting up neovim, the plugin manager and various sets and plugins that changed the usage and customization of the editor to make it cleaner and freshest while keeping everything at arms (or should i say fingers) reach.

After the installation was half-complete (for my taste and needs) i tinkered around looking for plugins that will make the editor the best way comfortable for me to switch to it full time. Part of the reason the idea of vim was hovering around over the past weeks was the vadelma theme that i could not find on vscode. It is safe to say that i ended up using the popular gruvbox instead.

Among the various plugins and sets i ended up installing (and updating), here are some worth noticing:

• nerdtree: Perfect way of rapidly showcasing and accesing the project tree files
• startify: vim home screen, helps you easily accesing recent buffers and files
• set number: Number display. You can make it relative if you want to
• set colorcolumn: If youve worked with previous lint or code validators, it helps displaying line limit
• ncm2 autocomplete: bufword, path, jedi (python)
• lightline: Inspired by Jon Gjengset rust videos, this status line blends beautifully with the editor

You can find the complete list here. Feel free to check the ones i have or suggest others.

Switching Editors

Before trying vim, my main editor of choice was a mix of vscode/jupyter notebooks (colab). I’ve previously used sublime, atom, xcode and replit online editor. However, due to the fact of my main needs and the data science trend to notebook-tify everything, vscode and colab worked along fine as my primary editors. Vim starting usage is hard, it gets easier every time (i am currently writing this blog post using it) but the learning curve sure is/was a bit challenging. On top of that, a common data science exploration and analysis code tends to use notebooks. Google colab suits this matter neatly. Inline plots, pre-installed common libraries, cloud-based storage, etc. make it the obvious choice when tackling data science / machine learning projects.

So… what fueled the change? First, my current job provided with some insights when dealing with notebook related workflows. I was working in productivizing some notebook works and oh boy do notebooks can be a bit tricky when productivizing them. A typical software engineering project has dependiencies (yaml, toml, etc), testing, debugging, lintin and such. When productizing notebooks, you either use it as an entry point or rather convert it to a python one (rather rewrite it instead of convert it). Notebook executions have to have a definied execution sequence and integration notebooks can be somehow challenging.

The idea of changing my current data science workflow from colab/notebooks to a local one was a bit complex. How can i have the best of both worlds: Getting the notebook smoothness of cell by cell execution, plotting, ease of exploration and fast-paced modification while, in the other hand, you have production-ready, maintanable and reproducible software.

Then i found Joel Grus conference on notebooks (link):

Joel covers (in an extensive and meme-able way) why he dislikes notebook, explaining key points considering reproducibility, bad habits, testability and more. Before the final Q&A section of the video, he demonstrates how could a typical data science workflow using IPython could work. With that in mind, plus a few IPython and vim videos i ended up setting my environment for working with data science workflows. Hooray!

Wrapping this thing up

The learning journey can only go on. I am deeply curious with this new set of tools and only can hope to keep learning. It may be possible that i missed some sources in this post, but in addition to the ones i previously mentioned, the missing semester vim session, vimtutor and xvzf’s vim for data science were extremely helpful. See you next time!