For the past 11 years, I’ve been a full-time software engineer. Today, I am sharing my typical set-up on my work machine.

There is perhaps two different ways I could have presented this, one was time-based then by the tools and another by time for each tool. I’ve chosen the former after first introducing the software.

Software

GNU Screen

A terminal-based windows manager that handles managing multiple terminal windows in one.

tmux

A terminal multiplexer, essentially an alternative to GNU screen.

Cygwin

A large collection of GNU and Open Source tools that aims to make it easy to build source meant for Linux and POSIX-based systems to run on Windows without needing to change the source.

For my most part my employer relied on Perl and XEmacs from Cygwin as part of their standard development environment when I started.

MSYS2

Similar to Cygwin but without relying on the translation layer and is built on MINGW (Minimalist GNU for Windows).

The two advantages of MSYS2 that were relevant to me over Cygwin were:

  • Better support for Windows programs, for example Ctrl + C actually worked properly (for years Cygwin developer’s view on the problem was that you should build your software for Cygwin).
  • Package manager, pacman made it far easier to upgrade software (mainly git) without having to rerun the graphical set-up program for Cygwin which was quite daunting.

2011 to MSYS2

Terminal

Terminal environment was through Cygwin.

I would have a terminal running Cygwin with GNU Screen. Typically, there would be 5 to 6 shells behind it, each shell goes to a different working tree. The first three shells are always pointed at trees that held the product I developed, the fourth and fifth was usually the 3rd party code and tooling. Once SSDs were introduced, the main working trees lived on the SDD with another of the old HDD so another shell would point to that.

For the front end, the screen would be split vertically, so I can see two of the shells visible and the rest in the background and can cycle to them if needed.

When our development moved to git, I started building git from source in-order to benefit from the newer features and fixes. Cygwin would often lag behind in releases.

A particular nice project around the time was PuTTYcyg which I later transitioned to Mintty.

Editors

Xemacs was in heavy use when I started, so I started on that. However, for Python scripting I still used SciTE, that I been using for years (since around 2005), likewise it was my go to for text editing.

It wasn’t until about a year or two in when there was a kind of IDE renaissance. This resulted in developers at the company started shifting away from Xemacs. In part this was due to the move to git as the previous workflow and tooling had been made for Xemacs.

I did set-up parts of that workflow in Visual Studio so I could use that for editing source, mainly for when I was debugging, and slowly started doing more development in Visual Studio.

I also moved from Xemacs (Cygwin) to emacs (Win32) at some point as well where I benefited from package manager that came with the newer version. The break through was when I discover ELPA and found it a lot more useful.

A key thing was using ELPA to install better themes as the commonly shared configuration had an painful high contrast colour scheme.

I do wish I had of documented my emacs use more.

Debugging

For debugging, Visual Studio was the king, when I started we were on 2005. The team I was on was the the last to make the switch to 2010 due to our pending releases at the time.

MSYS2 Era

The move to git marked end our the reliance of Cygwin and the elimination of many of the in-house tools developed that depended on Cygwin.

Terminal

At this point, I made the jump from GNU Screen to tmux, as far as I was aware the former was not available as an installable package for MSYS2.

The key difference for GNU Screen to tmux was the loss of the ‘cycle’. Instead of cycling a visible pane to another shell, my workflow changed to having multiple windows and switching between windows. This means all the shells change at once. So the first window become my main working trees, second window as alternate.

My monitors were upgraded so I was now able to fit 3 terminals vertically.

Editor

For C++ development, Visual Studio. For Python, Visual Studio Code.

Shortly after I switched to Visual Studio Code, I found myself rarely using emacs anymore.

Post MSYS2 Era

My employer started recommending using Git for Windows over Cygwin, so I eventually switched to that once I got a new machine.

Terminal

Git for Windows had a big disadvantage for me, it does not come with a package manager nor tmux or GNU Screen. At the time, it wasn’t easy to find a build for either and I wasn’t interested in building from source. The timing however was good because Windows Terminal was just coming onto the scene.

Now, I use Windows Terminal where the ‘windows’ in tmux are now tabs, and the panes are still panes. Of course, when I started using Windows Terminal these features were fairly new and weren’t even mapped to keyboard shortcuts out-of-box.

Editor

I do find myself doing more C++ development work in Visual Studio Code than Visual Studio. This really depends on the task and mostly its a reflection of that.

As for Python, I still use Visual Studio Code.