Over this winter break, I’ve had a lot of time to actually think about the technologies I use. Because this amount of time, I thought it would be good to experiment with new editors, make things look nice, and explore new ideas.

Editor History

When I first started to code, I used mostly Pycharm as I was learning Python at the time. It was nice for the python code I was writing at the time, but if I was to expand my language domain, I couldn’t only use PyCharm. This is where VS Code entered into the picture. vs code allows different for different coding environments for different programming languages all in one editor. Setting up a person’s environment involves using the extension marketplace that vs code offers, and developers have the option to develop their own extension (in typescript) to post on the public marketplace. VS code is considered to be an IDE (Integrated Developer Environment). IDEs streamline many of the desired features that a developer might want and more, so programmers do not have to spend time configuring. It’s on the philosophy of abstracting as much as one can to put focus on the problems that matter now. In return, vs code can be quite hefty in memory usage, since it packages many possible features together like syntax highlighting, debugging protocols, and more.

For some time, I’ve thought about moving over to Vi/Vim/Neovim to edit code. I heard about the improvements in productivity, and the satisfaction of work once a person understands Vim properly and uses it to the person’s advantages. For reference, Vi is the original modal editor preceding Vim and Neovim. It has a focus on using the keyboard keys and keyboard shortcutsinstead of using the mouse. The idea is the time saved from not lifting your hands off the keyboard will give noticeable improvements overtime. Vim is supposed to a more extensible version of Vi, the original modal editor. Vim is baked into most computers nowadays and can be booted with the vim command. Use the vimtutor command to get a tutorial on using vim. To extend vim, one can write plugins or extensions in a unique scripting language called vimscript, which basically is only used in vim. Neovim is supposed to be the extended version of Vim. Plugins for neovim can be written in the language, lua, a scripting language commonly used to make games, especially in the Roblox ecosystem. However, these improvements would come at the cost of spending much time upfront to understand new keybindings, configuring, and maintaning configs.

I always thought the idea of coding in a modal editor would be interesting, using less resources, and coding in the terminal would provide enough incentives for me to try a new editor. Also, with the break, I would have a lot of free time to explore and customize my editor and provide that up front cost. Another nice advantage of using nvim/vim as one editor is that much of your config can be migrated into the andrew machines and can be used there as well. To be sshed in andrew and use vs code, one must use an ssh client in vs code, which can cause more slow down and sometimes mess up the syntax highlighting and other useful features for writing c code.

Nvim and Plugin Hell

Because Nvim (Neovim) has a more community centered approach to plugins and extending the ecosystem, I thought to use neovim instead of pure vim. Installing neovim on mac is simple using brew, and one can simply use the curl command to grab the nvim image. The following is the curl command from the neovim github for installing for macOS. Other installation instructions are on the github.

curl -LO https://github.com/neovim/neovim/releases/download/nightly/nvim-macos.tar.gz tar xzf
nvim-macos.tar.gz ./nvim-macos/bin/nvim

Neovim doesn’t provide a well sourced document on navigating the entire plugin ecosystem. It’s hard to see the power of what neovim can provide seeing youtube videos redditor’s configs. A good source of information is one of the maintainers and developers of nvim, TJ DeVries. When I first started, I was mostly looking at him to see how to configure nvim with lua, interesting plugins that I didn’t know existed and commentary to keep me interested. ThePrimagen is also a nice source some nvim stuff although he does post other stuff besides nvim configurations. The initial setup phase can be somewhat dry as most people want the same few plugins like syntax highlighting, code snippets, etc. etc. It seems there seems be missing that sort of plugin or setup environment that would resolve those first few steps to get everyone up and running withouth headaches early on. Luckily, in my short time so far, I haven’t had my config broken with sudden changes. However, I had major issues when it came to installing plugins, migrating configs, and seeing if plugins that should have been installed were actually installed or not.

Initially, I was configuring nvim using the original init.vim. I wrote my basic configurations using vimscript and installed my packages with a package manager called vim-plug which made it very easy to install and get going with plugins. I heard of writing of configs in the lua language, but I wasn’t convinced initially to make the switch, and I would have to learn an entirely new language (in retrospect, its pretty simple. EVERYTHING IS A TABLE). However, as my config grew to around 100 lines of code, I ran into a default configuration for treesitter that was in lua, and I couldn’t find a default configuration in vimscript. Then at that moment, I decided to make the switch to port vimscript to lua code. Everything in lua is a table or function making it very simply to learn, and porting was made simple with the vim api. Instead of vim-plug, I used the packer package manager which allowed for asynchronous and lazy loading for more efficient installing and syncing of plugins. However, I would run into a problem that I wouldn’t be able to solve until after a few days. My treesitter syntax highlighting seemed to crash my entire nvim setup. After stripping my entire config into 10 lines to locate the issue, I threw up my hands, and decided to try a starter configuration, where someone already initally set up some basic defaults. However, the problem still remained, and I was still flabbergasted at what could be causing the problem. I even tried reinstalling the neovim image and to no avail. After some thinking, I thought that I hadn’t cleanly migrated my old syntax highlighting plugin (coc.nvim) to the new one (treesitter). I saw I could still use the CoC command, and I saw many old plugins still existed in my ~/.cache/nvim/ and ~/.local/nvim repos. After deleting these repos, the problem disappeared. All that headache due to caching. My second arose with my new package manager, packer. Oftentimes, when I wanted to install or remove a package, packer didn’t seem to want to install or clean the package. Sometimes, I’d have to delete all the packages, and then reinstall just for my package to sometimes be installed. It was rediculous type of petty bugs that I would encounter. I kind of liked my setup at the time, but I got massive headaches trying new things. I eventually thought it might be an interesting idea to restart from scratch again and use a predefined configuration to give me a good head start. I decided to run with (Astrovim)[https://github.com/AstroNvim/AstroNvim] as the homescreen looked nice, it wasn’t separate from neovim, and easily customizable. The actual install provided nice help into all the possible places where previous conifurations end up, that being in ~/.local/share, ~/.local/state, and ~/.cache. Astrovim also showed me terminal plugins that I didn’t even know that I wanted like (toggleterm)[https://github.com/akinsho/toggleterm.nvim]. The actual configuration in a user/init.lua file is nice, and I can edit the defaults as I please. After some initial hiccups, I have everything rolling, and this setup is currently what I have going right now.

Thoughts

In retrospect, I somewhat arrived back at the vs code implementation in neovim, but I don’t think of it as strictly unproductive. The whole journey that I’m still on has taught me more about the nature of reading documentation, and the skill of combing through large swaths of information to get what I want. It also showed weakness in many areas such as basic maintenance, debugging, and keeping calm when running into medium term problems. I remember, when I first thoguht of starting from scratch, I didn’t bother keeping a backup of my folders, I more or less mass deleted the files, and yoloed into installed astrovim, without even noting what my hold bindings were. Such half-hazardous ways of going about code would not be productive in the real software development cycle. I think if I can get on the level where I can write a small plugin for myself and make it public, it would also transfer into my swe skills. I’ll be more used to the act of reading through large documentation but sitll make contributions.

I’ve realized that I have the urge to dive straight into the code, or look for the perfect solution that works for me instead of investigating more research into documentation and informational google search. For example, I was starting to read up on DAP (Debugger Adapter Protocol), and was searching for ways to make it work for c and c++ code. I had a vague memory of doing it before, and I began bashing my head for days to figure out how to start the actual debugger. What I found much later, was after finally looking at the documentation, there were more instruction on providing debugger features in the compiler tool with a debugger flag. All of that time, lost sleep, and almost aha moments were all for naught as simply reading documentation instead of looking at half baked youtube videos or thinking the bug lay somewhere would have solved my problems. I think if I put more effort into the frontend of research and reading documentation, I’ll be more knowledgable and solve potential time sucking problem much faster. I believe the urge to dive into the code comes from getting into bugs and then dealing with them. I sometimes think that I might be spending to time looking at documentation as I tend to learn best through writing code that works. However, when code fails, I don’t learn, and I don’t have correct code either.

Much of my preparation is in due for next semester. I’m taking 17355, PnC, and 15213, all 12 unit coureses which is quite hefty, but I’m not the type to steer clear of a challenge. For the future, I want to get a better handle of working with git, documenting resources, reading documentation, and a better grip on neovim. I’m starting to realize that it is the tools that a developer uses is what makes a programmer productive, rather than the lines of code or the programming langauges I know. Plus, many headaches and bug-full nights can be taken care of when I can maintain code well. I plan on trying to learn about the doxygen engine and master the debugger for 213. It’s a lot of goals that I doubt all will be taken care of, but if I can achieve at least one, I’ll be pretty satisfied.