They've never broken my vim

They've never broken vim on my machine.

"They" being the developers. I'm sure they've pushed bugs (all sufficiently useful software has bugs), I'm sure they've done hotfixes and rollbacks and possibly delisted versions but they've never managed to break my workflow in the process. The vim I use today is fast, predictable and portable. The vim I used 10 years ago also was those things.

Part of this is that my vim workflow is admittedly amateur. I use a very small subset of commands and shortcuts, I pick up 1 or 2 every year that stick and broadly I am happy with the experience I get. vim doesn't get in my way. My vimrc is 72 lines including comments and line breaks. 46 lines of actual commands. I don't use plugins, I don't use anything that I would miss were I stuck ssh'ing on some box to fix a problem or investigate an issue. While that seems less and less likely every day in the beginning of my career it was a common occurrence to debug production issues by SSH'ing onto a server and searching through logs manually and editing configuration files.

History repeats itself

An editor that does anything but simply manipulate text is doomed to fall under it's own weight. Much like every project management software eventually becomes Jira, every "IDE" or "IDE-lite" eventually just becomes Visual Studio.

1. Become dissatisfied with the state of modern IDEs, develop a lean one with a focus on X
2. Gain marketshare as developers view you as "a breath of fresh air" and the "lightweight IDE we needed"
3. Listen to user feedback and add feature Y which "was the only thing stopping this editor from being perfect"
4. Continue chasing more and more functionality to achieve your goal of X
5. Repeat Steps 3 and 4 until you've created a slow frankenstein monster that can't open a 1GB text file without completely locking up
6. Congratulations, you're now the thing you hated! GOTO Step 1 again or someone else will!

This has happened with every "IDE-lite" project that has ever existed and people still have not learned. VSCode is slowly just becoming Visual Studio. IntelliJ became just as slow as Eclipse. Zed has focused on advanced features and let basic bug fixing and performance fall by the wayside.

Unix Philosophy

The unix philosophy is as applicable here as anywhere else. Foundational tools should focus on doing one thing really really well. Some would argue that still holds in this world since underpinning these IDEs are build tools, LSPs, static analysis tools and compilers. Unfortunately the people using these tools don't really see them that way. The "play button" developer sees all of these things as friction to finishing their ticket. They see the underlying technologies as a hurdle to clear to get where they want to be rather than the mechanisms by which they can achieve things.

Not every developer who uses these tools is an idiot but after a few cycles of being tossed around the life-death-and-rebirth of editors one has to eventually learn the lesson. If a developer is willing to accept the eventual enshittification of their development environment because the benefits are worth the cost then I at least respect that position. Go in eyes wide open.

On editors and AI

There's a mad dash to integrate AI tooling and agentic workflows into editors. I think this is largely a mistake. JIRA, Slack and other project management/communication tools will win that war. If you're already ceding control over to the machines and becoming a glorified PR reviewer there's little to no value once these systems get good enough for them being in the editor. Go one level higher, review the code there.

AI forward editors like Cursor and Windsurf (who have done an admirable job pivoting to looking more like a communication interface) seemed doom to fail IMO.

Conclusion

All of this is to say that the I am not against using a different editor but that it would be difficult. vim has been good to me and I've gotten to watch the hype cycle of editors wax and wane from a pleasant distance. I'm also not sure software is being written anymore like it was when vim was being written. Even modern open source editor now has corporate overlords and "open-core" companies backing them. Despite their perceived firepower I don't particularly trust the open-source stewardship of a large company.

Here's my current .vimrc

"general settings
syntax on
set nocompatible
set noswapfile
set noerrorbells
set splitright
set splitbelow
set wildmenu
set autochdir
set autoindent
set cindent
set background=light
set ruler
set clipboard=unnamed
set backspace=indent,eol,start
set visualbell
set t_vb=

" Hybrid Line Numbers with focus
set number relativenumber

augroup numbertoggle
 autocmd!
 autocmd BufEnter,FocusGained,InsertLeave * set relativenumber
 autocmd BufLeave,FocusLost,InsertEnter * set norelativenumber
augroup END

" display tabs, trailing characters, and non-nreaking spaces
exec "set listchars=tab:\uBB\uBB,trail:\uB7,nbsp:~"
set list

" tab settings
set tabstop=2
set shiftwidth=2
set softtabstop=2
set expandtab

set ignorecase " Do case insensitive matching
set smartcase " Do smart case matching
set incsearch " Incremental search
set hidden " Hide buffers when they are abandoned

" undo file
set undofile
set undodir=~/.vim/undo
set undolevels=1000
set undoreload=1000

autocmd FileType yaml,yml setlocal ts=2 sts=2 sw=2 expandtab
autocmd FileType sql setlocal ts=2 sts=2 sw=2 expandtab
autocmd FileType go setlocal ts=2 sts=2 sw=2 noexpandtab

" turns off the highlighted search when pressing enter
nnoremap <CR> :noh<CR><CR>

" highlights words matching the word under the cursor with F8
nnoremap <F8> :let @/='\<<C-R>=expand("<cword>")<CR>\>'<CR>:set hls<CR>

" highlights characters past 120 w/ colorcolumn color
" highlight ColorColumn ctermbg=None ctermfg=red
" let &colorcolumn=join(range(121,999),",")

" maps 'W' to write (same as 'w')
command! W write

" Set netrw style
let g:netrw_liststyle = 3
let g:netrw_banner = 0

" Sean Section (Delete if bad)
set scrolloff=2
inoremap <S-Tab> <C-n>