
As software developers we spend a lot of time in a code editor, so it is important to choose one that you feel comfortable with and enjoy using. Vim (or Neovim in recent years) has been that choice for me. I love how it allows me to efficiently navigate and edit text while keeping my fingers on the keyboard. Other things that are crucial for me are its speed and the ability to run in a terminal (Seamless integration with tmux). I have been using Vim for more than a decade and have no plans on switching to another editor any time soon. 

Nothing is perfect though; even Vim has its flaws. Let's have a look at some of these, based on my own experience.


## Wasting time on configuration

One of Vim's greatest benefits is the ability to customize pretty much anything you can think of. If there's something you don't like, you can change it. If some functionality is missing, you can add it. There's always something to tweak or improve. However, this flexibility comes with a danger: If you're not careful you can get lost in spending endless hours on your configuration.  
Reflecting on all the time spent configuring Vim, which I could have used to write code instead is kinda regretful. There have definitely been weekends were I planned to work on a side project, but ended up tweaking my `.vimrc` file instead.

I do enjoy tweaking my configuration, so calling it a waste of time might be a bit harsh. It is time that probably could have been spent better though.

One way to avoid spending too much time on configuration is to use one of the open-source setups available, such as [LazyVim](https://www.lazyvim.org). I haven't tried any of these myself as I'm quite happy with my current setup, but I do see the appeal it.


## Plugins for everything

By default Vim looks like a very basic text editor. To get some of the functionality that is included in modern editors by default, you often have to rely on plugins. There are plugins available for pretty much everything you can think of. In the rare case you cannot find a plugin for something, there's always the option to write it yourself.

This provides a lot of flexibility, but it also means that all these plugins (44 in my case) need to be configured and maintained. It is not uncommon for one of the plugins to contain a breaking change after an update, resulting in me having to debug why my editor is not working as expected. Or guessing what is causing the cryptic error at the bottom of the screen.  
More often than not are there multiple plugins available for the same functionality and deciding which one to use can be confusing. For example: Getting LSP and linting working can be quite a challenge due to the fragmented ecosystem.

Of course there is always the option to take a minimalist approach and install as few plugins as possible. No one is forcing you to install a plugin for everything. However plugins are essential if you're looking for a modern editor experience.


## Using a different editor than your Colleagues

While there is a large online community of Vim and Neovim users, coming across a colleague that uses Vim as their default editor is not that common. Especially if you're working at a smaller company. Most people seem to be using VSCode these days.
Of course this is not a huge problem and everyone should be able to use the editor they like. Pair programming however is much easier when both developers are using the same editor. VSCode has an extension that makes it very easy to have a remote pair programming session with another VSCode user. As Vim user you occasionally might have to be flexible and adapt to whichever editor your colleague is using.

Using Vim at work everyday, but not being able to share your passion for it, can sometimes feel a bit isolated as well. Please don't be that guy that keeps preaching to everyone about how great Vim is.


## Vim motions don't work everywhere

Once you have the Vim key bindings engraved in your muscle memory, you want to use them everywhere. Unfortunately the reality is that we have to write text in a lot more places other than our text editors. During my job I have to communicate through Slack, write tickets in Jira or write a document in Google docs. Writing text in these places feels unnatural when you're used to Vim.

Sometimes I write the text in Vim first just to copy and paste it into the other text input. This is definitely not the most efficient way to do things. In a perfect world every text input field would support Vim key bindings.


## Choosing the right editor

When deciding to use Vim as your editor, consider the points mentioned here. I've listed them as downsides, but they won't stop me from using Vim. I don't see them as deal-breakers, but they might be for you. Over the years I've adapted and learned to live with it. Moreover I believe that the benefits of using Vim by far outweigh the negatives.

I expect to happily keep using Vim in the foreseeable future. Every other code editor that I've tried in the past had its own set of problems; often much bigger than the ones mentioned in this article.

For me Vim (or Neovim) is still the best editor out there.


The downsides of using Vim


A few months ago Bram Moolenaar passed away. He is responsible for creating Vim, the text editor that I use on a daily basis. It's not just any editor, but one that I have absolutely loved since the first day I tried it. Having been a Vim user for many years, this unfortunate event seemed like a good moment to take a look back at my journey with this Vim.
Curious to know how long I have been using Vim, I searched the Git history of my Dotfiles repository to find out that the `.vimrc` file was added on June 23, 2013.

Apparently I have been using Vim for over a decade now…


## How did I get started?

I have always been the type of person who wants to use the best tools available, even if I am already using something that is good enough. After reading about this editor called Vim and how it allows you to edit text without having to use a mouse, I got very curious.  
These days YouTube is full of video's demonstrating the possibilities of Vim or Neovim, but this wasn't exactly the case 10 years ago. However I do remember one video quite well, which is this one by Ben Orenstein: [Write code faster: expert-level vim](https://www.youtube.com/watch?v=SkdrYWhh-8s). I found it very impressive and after seeing it I was sold. Vim had to be my new text editor.


## Learning how to use it

I remember quite well the resources that I used to learn Vim. I followed the Vim Tutor, which is an interactive tutorial that comes installed with Vim itself. It can be opened by running `vimtutor` on the command line. This will only teach the absolute basics, but it's sufficient to be able to navigate, edit files and most importantly: exit Vim.  

The next thing I did was print out a cheat sheet ([This one](/images/vim-cheat-sheet.gif)) and have that next to my keyboard all the time. In the beginning I mainly used it to look up the basic things like navigating. Later I also went through every key on the sheet to learn what it can be used for until I had memorized everything. I think that was also the moment I felt confident enough to start using Vim as my main editor.

Another resource from which I learned a lot, was [Vim Casts](http://vimcasts.org/) by Drew Neill. These were short videos, all focused on how to do a single thing with Vim. Especially the videos on how to use Fugitive, a Vim plugin for using Git, were very helpful.

## Making the switch from Sublime

Before this I was using Sublime Text as my main editor. It's an amazing editor and like Vim quite fast as well. I don't recall having any complains about it at the time, but I quickly became so obsessed with learning Vim and using it that I replaced it with Vim as my main editor. This went pretty well for the first few weeks…

Until I got a new job.

Remembering all the key mappings appeared to be a lot more difficult when there's also the pressure of getting used to a new working environment. Even more so when a colleague is sitting next to me staring at my screen.  
I decided it would be better to move back to Sublime Text and give Vim another try after I became completely accustomed to my new job.
Not long after that I discovered that Sublime Text had **Vintage Mode**. This allowed me to use Vim key bindings, while still being able to use all the features from a regular text editor. The best of both worlds. No more stress when I needed to copy and paste something while I was getting help from a colleague.

This transitional period must've taken around 3-6 months. I was using Sublime Text with Vintage Mode at work, while using Vim for everything in my own time. Working in Vintage Mode was quite enjoyable, but also limited compared to what Vim is capable of. I wanted to be able to use all the cool tricks I learned, use Vim plugins and use my own Vim configuration. Once I felt confident enough in both my Vim skills and my job, I decided to take the plunge. I left Sublime Text behind for good.


## tmux

In the beginning I was mostly using MacVim, the GUI version of Vim. As I started doing more and more on the command line, I switched to using Vim in the terminal as well.
While modern terminal emulators have support for tabs and split panes, using it always felt a bit clunky.
That's when I discovered tmux. This is a terminal multiplexer that makes it possible to have multiple terminal sessions in a single screen. 

With a few changes to my `.vimrc` and `.tmux.conf`, the combination of Vim and tmux worked seamlessly. Navigating between Vim buffers and the terminal sessions became effortless while only using the keyboard. I absolutely loved it, there is no way turning back now.


## Using Vim on a daily basis

Vim is my preferred text editor whenever I need to write something on the computer. I use it for writing code, commit messages, notes, and of course for writing this blog. Even when I need to write text in a program that doesn't support Vim bindings, I often write it out in Vim and then copy and paste it into the other application, such as emails or lengthy WhatsApp or Slack messages. Now that I am so accustomed to the Vim key bindings, writing text without them feels unnatural.

These days I use Neovim, which is a fork of Vim that focuses on extensibility and usability. Most modern plugins are developed specifically for Neovim, so I decided to make the switch about three years ago. One of the biggest benefits is that Neovim has support for Lua, making customizing the editor much easier than with Vimscript.


## The future

Even after 10 years it is a great pleasure to work with Vim everyday. The speed and ease at which I can edit text still feels like having super powers. The key bindings are so deeply engraved in my muscle memory, that it is hard to imagine ever using anything else. Whenever I need to write text somewhere that doesn't support Vim key bindings, I feel out of my element.

While I consider myself to be a very proficient Vim user, there is still a lot room for improvement. In both the way I use it to edit text, as well as in my configuration.
This is also what makes it appealing to me: There is always something new to learn or something that could be optimized further.
Using Vim never gets boring, even after a decade.

Thank you Bram for creating this fantastic piece of software 🙏


Reflecting on a decade of Vim


There has always been some inconsistency between the behaviour of array methods in JavaScript. Some of the methods are mutating and change the original array on which they are called, while others leave the original array untouched and return a new array.  
Methods like `map()`, `filter()` and `reduce()` do not modify the original array; they create and return a new one instead. On the other hand, methods like `sort()`, `reverse()`, and `splice()` are mutating and change the original array.

## Mutation is often undesirable

Mutation refers to the act of changing the state of an object or data structure after it has been created. And while is not necessary always bad, it does have the potential of leading to unexpected behaviour and bugs. For this reason it is often recommended to avoid mutation if possible. When working with state in React it is even a requirement: All state updates have to be immutable. The new state must be a completely new value otherwise it won't trigger at re-render.

To use the mutating array methods without changing the original array a common work-around is to first create a copy of the original array before calling the method on it.

```typescript
const original = ['c', 'a', 'b']

// Use spread operator to clone (shallow) the original array
const sorted = [...original].sort()
console.log(sorted) // ['a', 'b', 'c']

// The original array is unchanged
console.log(original) // ['c', 'a', 'b']
```

While this works fine, it would be far more convenient if we didn't have to think about
accidentally updating the original array and making sure to create a copy first.
Thankfully ES2023 brings us a few new array methods that give us the comfort of knowing that the original array stays untouched when they are called. This means it is no longer necessary to copy the original array first.

## ES2023 introduces 4 new array methods

Among the new features in ES2023 are 4 new array methods which do not mutate the original array:

- `toReversed`: Reverse an array
- `toSorted`: Sort elements in an array
- `toSpliced:` Remove, replace or add elements in an array
- `with`: Change value at array index

All these methods return a new array and leave the original array untouched.
The names of the first 3 might look familiar; they are indeed the non-mutating versions of
`reverse()`, `sort()` and `splice()`.
Let's have a look at each of these methods, see what they do and how they compare to their mutating counterparts.


### Array.prototype.toReversed

The `toReversed()` method, as the name suggests, returns a new array with the elements in reversed order. Unlike the `reverse()` method it does not mutate the original array.

```typescript
const arr = ['a', 'b', 'c']
const reversed = arr.toReversed()

console.log(reversed) // ['c', 'b', 'a']
// The orignal array is untouched
console.log(arr) // ['a', 'b', 'c']
```

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toReversed) for more details about `toReversed()`


### Array.prototype.toSorted

To sort an array without mutating the original array, the `toSorted()` method has been added. 
If it is called without argument it will return a copy of the array in alphabetical order.

```typescript
const arr = ['c', 'b', 'd', 'a']
const sorted = arr.toSorted()

console.log(sorted) // ['a', 'b', 'c', 'd']

// The orignal array is untouched
console.log(arr) // ['c', 'b', 'd', 'a']
```

Its sorting behaviour is the same as the mutating `sort()` method, so only an array of strings can be reliably sorted by calling `toSorted()` without arguments. To sort anything other than strings we can provide a compare function.

```typescript
const arr = [9, 13, 20, 7]
const sorted = arr.toSorted((a, b) => a - b)

console.log(sorted) // [7, 9, 13, 20]

// The orignal array is untouched
console.log(arr) // [9, 13, 20, 7]
```

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted) for more details about `toSorted()`


### Array.prototype.toSpliced

The `toSpliced()` method can be used to remove, replace or add items in an array without modifying the original array. It works similar to the original `splice()` method.

It accepts the following parameters:
- `start`: The index at which to start changing the array
- `deleteCount` (Optional): The number of elements to remove from start index.
- `item1, item2, ...` (Optional): These items will be added to the array at the start index.

```typescript
const arr = ['a', 'b', 'c', 'd']

// Insert new element at index 2
const inserted = arr.toSpliced(2, 0, 'x')
console.log(inserted) // ['a', 'b', 'x', 'c', 'd']

// Remove 2 elements at index 1
const removed = arr.toSpliced(1, 2)
console.log(removed) // ['a', 'd']

// Replace element at index 2 with 2 new elements
const replaced = arr.toSpliced(2, 1, 'x', 'y')
console.log(replaced) // ['a', 'b', 'x', 'y', 'd']

// Original array is untouched
console.log(arr) // ['a', 'b', 'c', 'd']
```

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSpliced) for more details about `toSpliced()`

### Array.prototype.with

The `with()` method can be used to change the value at a specific index in an array.
It takes two parameters: The index and the value that should be set at the given index.

```typescript
const arr = ['a', 'b', 'c']
const newArr = arr.with(1, 'd')

console.log(newArr) // ['a', 'd', 'c']

// The orignal array is not mutated
console.log(arr) // ['a', 'b', 'c']
```

This can be seen as the non-mutating equivalent of the bracket syntax to replace a value: `arr[index] = newValue`.

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/with) for more details about `with()`

## Can these new array methods be used today?

Even though ES2023 hasn't officially been released yet (May 2023, as of writing), some browsers have already implemented support for these new array methods. However not all major browsers support it yet (Looking at you Firefox). If you want to start using any of the new methods today, it is recommended to use a polyfill like the one from [core-js](https://github.com/zloirock/core-js#change-array-by-copy).

The addition of the new array methods is a very welcome improvement to JavaScript and can help avoid unintentional mutations in our code. I'm looking forward to making this my go-to whenever I need to modify an array. If you prefer writing code that avoids mutations like me, then these methods will definitely make our lives easier.


Change arrays by copy with ES2023


These are 2 common situations we run into as software developers using Git. 
- You're working on a feature branch and suddenly need to switch to another branch to fix a bug.
- You want to update your local branch with the latest changes from the remote repository.

In both cases you often have uncommitted changes that need to be stored somewhere. Making a temporary commit would work. Another way to store these changes is by using Git stash. Running `git stash` will save the changes and to retrieve them later we can use `git stash pop`.

Stashes are stored in a stack which means that the last item added, will be the first item that comes out.
That is if we only rely on the push (`git stash push` or the short form `git stash`) and pop (`git stash pop`) methods. While this works fine for a lot of use cases, it has the potential to become problematic when there are multiple items in the stack and we want to retrieve an item that isn't the most recent one.

Fortunately, Git stash provides a way to efficiently handle multiple stashes. In this article I will show the commands and flags that I regularly use and hopefully help improve your Git workflow when working with stashes.


## Naming stashes

It is easy to lose track of the changes when there are multiple stashes. Fortunately it is possible to add a message when creating a new stash. For that we can add the `-m` flag with a message. For example:

```bash
$ git stash -m 'refactor payment'

$ git stash list

stash@{0}: On main: refactor payment
stash@{1}: WIP on main: 89da19c Update meta description
```

Instead of `WIP` and the last commit message, it now shows the stash with our custom message. Which makes it much easier to identify when we want to start working on the stashed changes again. This is why I make it a habit to always attach a message whenever I stash some work. Even when I'm pretty sure I will very soon continue working on the stashed changes.


## Untracked files

One cause of confusion for a lot of people (Including me in the past), is that untracked files are not included in the stash by default. So when new files have been created and we run `git stash`, these files will not be included in the stash and still be available in the working directory. 

To make sure that new/untracked files are included in the stash we can use the `--include-untracked` or `-u` flag. This will add all untracked files to the stash. For example:

```bash
$ git stash --include-untracked
```


## See what has been stashed

To see everything that has been stashed, the `git stash list` command can be used. This will show a list of all stashes with the last stash at top and the oldest at the bottom.  
All stashes will have the following name format:

```bash
stash@{<index>}: WIP on <branch>: <latest commit hash> Commit message
```

For example

```bash
$ git stash list

stash@{0}: WIP on develop: 5a22ab2 Add content
stash@{1}: WIP on main: 89da19c Update meta description
stash@{2}: WIP on main: 89da19c Update meta description
```

The default stash name only tells us the branch and the last commit at the time of the stash, but nothing about the changes that we have stashed. We can view the changes in a specific stash by using the following command: `git stash show -p <index>`. Where `<index>` is the number shown between the curly braces `stash@{2}`. By adding the `-p` or `--patch` flag, it will show the actual code changes in the output, instead of just the filenames with the number of changes.
I regularly use this when there are multiple stashes and I want to see what changes a specific stash contains. Or if I have old stashes for which I don't remember what they contain.


## Retrieving a specific stash

The changes from a specific stash can be retrieved with the `git stash apply` command. This will apply the changes from the stash to the working directory, but will keep the stash in the stack. When called like this without any additional arguments, it will apply the most recent stash. To apply a specific stash we can use the `git stash apply <index>` command. In older versions of Git (pre 2.11) instead of just the index, the full stash name had to be used. For example `git stash apply stash@{2}`.

For example:

```bash
$ git stash list

stash@{0}: WIP on develop: 5a22ab2 Add content
stash@{1}: WIP on main: 89da19c Update meta description

# Apply the most recent stash
$ git stash apply

# Apply the stash at index 1
$ git stash apply 1
```

Of course it's also possible to use the `git stash pop` command to apply the changes. This would also immediately remove the stash from the stack. This is the same as running `git stash apply` followed by `git stash drop`.


## Deleting stashes from the list

After applying the stash with `git stash apply` the stash will still be kept in the stack. This means that after a while the list of stashes can become quite long, which makes it harder to keep track of what is in each stash.

To remove a single stash we can use the `git stash drop <index>` command. Where `<index>` is the number shown between the curly braces, such as `stash@{2}`.

To remove all stashes from the stack at once we can use the `git stash clear` command. Be cautious with this command as it will remove all stashes and there is no way to get them back. This is probably also the reason why I seldom it.

```bash
$ git stash list

stash@{0}: WIP on develop: 5a22ab2 Add content
stash@{1}: WIP on main: 89da19c Update meta description
stash@{2}: WIP on main: 89da19c Update meta description

# Remove the stash at index 1 (stash@{1})
$ git stash drop 1

# Remove all stashes
$ git stash clear
```


## Conclusion

Git stash is a very useful tool to temporary store uncommitted changes when we need to switch branches or pull changes from remote. By making use of commands other than just `git stash` and `git stash pop`, working with stored changes becomes much more convenient.
Hopefully this article has shown you some new commands and flags to make working with Git stash easier and helps you improve your overall Git workflow.


Get in touch

Articles

The downsides of using Vim

Reflecting on a decade of Vim

Change arrays by copy with ES2023

Manage uncommitted changes with Git Stash