Changelog Interviews Changelog Interviews #340

All things text mode

We’re talking all things text mode with Lucas da Costa — we logged his post “How I’m still not using GUIs in 2019” a guide focused on making the terminal your IDE. We talked through his Terminal starter pack which includes: neovim, tmux, iterm2, and zsh by way of oh-my-zsh, his rules for learning vim, the awesomeness of CLI’s, and the pros and cons of graphical and plain text editors.


Sign in or Join to comment or subscribe


2019-04-07T18:04:26Z ago

I’ve got a 10 year old netbook that I use for school (because I won’t miss it if it walks off or gets damaged). I’m running Ubuntu 18.04 with no GUI and rarely get above 6% memory usage.
It’s been more than adequate for my CS classes so far. Even when I have access to a more powerful machine I find myself SSHing into it for coding tasks.

Great show; I’m going to try to incorporate quite a bit into my CLI lifestyle.

2019-04-17T07:10:04Z ago

Hi, very much enjoyed this episode. I converted from windows/vs (qt-creator/clion/rubymine/ecipse/notepad++/..) to manjaro/gvim about 2.5 years ago.

I just wanted to say that vim/gvim since 8.1 has asynchronous jobs now too, which somewhere in the episode was stated nvim had over vim. I really like the idea of nvim, but for me gvim still works better with some plugins I like. I also don’t like to use vim in the terminal, gvim allows for a bit more gui configuration/decoupling colors/highlighting from terminal colorpallette (or I don’t understand how colors work in terminals? as I understand you have many color possibilities (256 or 16bit), but you have to choose 16 specific colors in the terminal, and that’s what is available to tmux/vim, please do correct me on this if I’m wrong). For nvim I haven’t found a good gui wrapper yet, they seem incomplete/slow/render things wrongly, or trying to do things I don’t care about. Though I expect I will transfer to nvim at some point.
I’ve written 2 minor vim plug-ins very tailored to how our code is organized at my job, and for that it would be nice to just use python instead of having to create a vim-script layer between it and vim as I do now (though I do also think it is possible to only write python in a plugin for vim).

Personally I do use many many plugins (almost 70 at this point), but it takes a time to really understand and configure them all properly so they don’t get in the way of each other and actually help you in a significant way, it’s a constant search but it feels like a hobby to me, and code editing almost feels like playing a game now.

I have a sort of install script for my vim/zsh/dot files/applications I depend on (fzf/ripgrep/..), for mac/linux/windows which allows me to clone a repository, run one command and I am set. So when I have to log into a remote machine, I ask for/create a new user, and install my scripts, it takes about 10min for it to finish, and everything is just perfect :D (though that script atm only works well on linux, as with all the things, under constant evolution).

Jerod Santo

Jerod Santo

Omaha, Nebraska

Jerod co-hosts The Changelog, crashes JS Party, and takes out the trash (his old code) once in awhile.

2019-04-17T13:22:56Z ago

70 vim plugins! That’s impressive. Do you find that Vim runs slower with that much extra code in action? I use only a handful of plugins yet there are times when Vim chunks down and can’t keep up with my fingers…

2019-04-17T14:36:27Z ago

Yeah, its a bit of a chore. I stopped using some plugins because of this, or I search by trail and error for which feature in the plugin that is causing slow downs and disable that feature, reading issues on their github page can help sometimes to find these settings.

It heavily depends on the plugins themselves, most of them do not use the keypress event or something like that to trigger functionality, and just sit there waiting for me triggering them with a command, and if they implement it correctly they have no impact on the vim bootup time. As an illustration I just profiled my vim bootup time (built in feature), which is 155ms, of which 25ms is my own vimrc, and 22ms is from my own plugin (I didn’t do it in the right way :) )
Furthermore as I pointed out, there now are the asynchronous jobs and timers plugins can use, and I guess most do, so they have minimal impact the GUI/typing experience.
And, I use a good desktop machine at work and at home, on my 4 year old i5 dual core laptop it doesn’t work fast enough for actually doing real work, though I use it in a screen sharing situation sometimes when I am in a meeting room. Also on windows it doesn’t work as fluently, but I still use it over any other editor, as it is not slower than say Visual Studio 2017 with Visual Assist (not tried 2019 yet).

Vim and their plug-ins keep evolving, even in my 2.5 years of use I noticed imo important changes in the ecosystem, e.g. the asynchronous jobs are fairly recent and had a huge impact, and also since Visual Studio Code, MS defined the open Language Server Protocol for completion engines, for which there are some implementations for vim/nvim, which can use completion engines created for this protocol. This makes supporting semantic completion/documentation/goto/find_references for a variety of languages much easier and consistent (using coc.nvim for this atm, really fast growing and impressive project).
It’s definitely a continuous investment to keep things running smoothly and have all the latest features setup the way you want to, constantly on the hunt for a better way/plugin to do things.

2019-05-20T11:50:29Z ago

I’m late to the party but 100% on-board with striving for less. I especially loved the comment about customizing bash to do an ls after a cd. In fact, devs should create their own domain-specific language with Bash aliases. As an example, I have a way to capture directories into env vars for later reference … see this link

Player art
  0:00 / 0:00