I know, I know. Another "why I switched editors" post. But hear me out—this time it actually stuck, and I think I've finally figured out why.

The Reality Check

After years of hopping between Vim, Emacs, and VSCode, I've settled into a workflow that's honestly just... practical. I use GoLand for Go and frontend development, and CLion for exploring raylib and other C/C++ (or Odin with Odin plugin) projects.

The thing is, I had some WebStorm experience before—maybe a month or two here and there between my various editor adventures. But this time, something clicked differently.

What VSCode Got Wrong (For Me)

Don't get me wrong, VSCode has incredible out-of-the-box support for most technologies. But its UX just never sat right with me. Take project-wide text search, for example. VSCode crams those results into a tiny sidebar that's genuinely painful to navigate. Compare that to Vim's quickfix list or Emacs' xref results—even these supposedly "rudimentary" editors (spoiler: they're not) handle search results way more elegantly.

Build configuration is another pain point. Maybe I'm missing something, but I've never been able to wrap my head around VSCode's build configuration with those JSON files. In Vim, you set makeprg and you're done. In Emacs, you configure a compile command or use async shell commands. Simple. Intuitive.

That workflow never clicked for me. Zed gets this right—you can run arbitrary commands and bind keys to re-run them. JetBrains takes a similar approach but excels especially when it comes to running tests, debugging, and build configurations—it's all just straightforward and works without fighting the tool.

Why JetBrains Just Works

Here's the thing about JetBrains IDEs: they actually live up to that "it just works" promise, but in a more real way than VSCode ever did for me.

Setting up builds, running tests, debugging—it's all straightforward. No hunting through documentation to figure out which JSON schema you need. No wondering why your launch configuration isn't working. You just... do the thing you want to do.

Sure, JetBrains IDEs aren't as keyboard-driven as Vim or Emacs out of the box. But here's where it gets interesting: I found some JetBrains plugins that make the editing experience much closer to Emacs. This gave me the best of both worlds—JetBrains' excellent tooling with more familiar keybindings and editing patterns.

The Right Tool for the Job

These days, my setup is simple:

• GoLand for Go + frontend work

• CLion for exploring raylib, etc

Here's something interesting about JetBrains' licensing: you don't actually need WebStorm if you have GoLand. Any upper-tier IDE like GoLand, IntelliJ IDEA Ultimate, or CLion includes all the WebStorm functionality built right in. So even though I do web development at work, GoLand handles JavaScript, TypeScript, React, and all the web technologies just as well as WebStorm would. It's essentially WebStorm plus Go support, not a separate thing entirely.

Also worth noting—JetBrains offers free non-commercial licenses for many of their IDEs like CLion, Rider, and WebStorm, which makes experimenting with different tools much more accessible.

This feels more mature than trying to make one editor do everything, while also being more practical than juggling multiple specialized tools when you don't need to.

I still use Cursor occasionally for AI capabilities, but when I'm actually writing code? JetBrains runs the show.

Looking Back at the Journey

My editor journey—Vim → Emacs → VSCode → JetBrains—wasn't really about finding the "best" editor. It was about finding what works for me, right now, with the kind of work I'm doing and the setup I have.

Will I switch again in the future? Maybe. But for now, I'm not fighting my tools anymore. I'm just getting work done.

And honestly? That feels pretty good.

What's your take on the great editor debate? Have you found your "final" editor, or are you still on the journey? Let me know in the comments below.

I had previously used Odin while building the Jack compiler for my Nand2Tetris projects last year, and I really enjoyed the experience.

As I began reimplementing my interpreter in Odin, I realized I’d never actually dealt with reading interactive user input from the command line. Since I needed a REPL, this was a must. Surprisingly, just like Go’s bufio pattern, it’s not super obvious how to do this in Odin either.

After digging around in the Odin Discord, I found how to do it.

And here is a REPL that echoes your input:

package main

import "core:bufio"
import "core:fmt"
import "core:os"

main :: proc() {

    scanner: bufio.Scanner
    stdin := os.stream_from_handle(os.stdin)
    bufio.scanner_init(&scanner, stdin, context.temp_allocator)

    for {
        fmt.printf("> ")
        if !bufio.scanner_scan(&scanner) {
            break
        }
        line := bufio.scanner_text(&scanner)
        if line == "q" {break}
        fmt.println(line)
    }

    if err := bufio.scanner_error(&scanner); err != nil {
        fmt.eprintln("error scanning input: %v", err)
    }

    free_all(context.temp_allocator)
}

I've always preferred Emacs-style editing, especially the way it handles cursor movement and text manipulation. Even though I have switched to using VSCode for most of my development work, I often found myself missing the intuitive keybindings from Emacs.

Initially, I tried manually configuring my keybindings in VSCode, but this became tedious. Every time I reinstalled VSCode or set up a new machine, I had to manually copy over my settings or sync them using vscode settings sync feature. This led me to think: what if I packaged my keybindings into a VSCode extension?

The Idea: Automating My Keybinding Setup

Rather than relying on syncing my settings, I decided to create a self-contained VSCode extension that would automatically apply my preferred Emacs-like shortcuts. This way, I could install it on any machine with a single command, and it would just work.

Building the Extension

Setting Up the Project

To create a VSCode extension, I used the official Yeoman generator:

npx yo code

This guided me through setting up a basic extension. Since my extension was just about keybindings, I didn’t need to write any actual JavaScript or TypeScript code—just modifying the package.json file was enough.

Defining Keybindings

In package.json, I added my custom keybindings under the contributes.keybindings section. Here’s an example of what it looked like:

"contributes": {
  "keybindings": [
    {
      "key": "ctrl+a",
      "command": "cursorHome",
      "when": "editorTextFocus"
    },
    {
      "key": "ctrl+e",
      "command": "cursorEnd",
      "when": "editorTextFocus"
    }
  ]
}

This mapped Ctrl+A to cursorHome (move cursor to the beginning of a line) and Ctrl+E to cursorEnd (move cursor to the end of a line), mimicking Emacs behavior.

Why This Was Worth It

Now, instead of manually managing keybindings across machines, I can just search for my extension on VSCode and install it.

This has saved me time and made my VSCode setup much more portable. Plus, since it’s on the marketplace, other Emacs users can benefit from it too!

What’s Next?

Publishing my first VSCode extension was easier than I expected, despite the initial hurdles. Now, I’m thinking about:

• Exploring more about VSCode extension development and seeing what other customizations I can make.

• Exploring the possibility of building different extensions to further customize my VSCode workflow.

If you're interested in customizing your VSCode experience, I highly recommend trying to write your own extension—it's simpler than you might think!

Get the Extension

You can find my extension on the VSCode Marketplace. Let me know if you find it useful!

https://marketplace.visualstudio.com/items?itemName=bhanuka.bmax-emacs

Sometimes, you might want to keep your dependencies within your project directory, whether for portability, version control, or simply to avoid installing extra packages globally. Here’s how I set this up with CMake. Updated CMakeLists.txt Example for Local Libraries

This is the setup I use to link Raylib (a popular C library for game development) directly from my libs folder.

cmake_minimum_required(VERSION 3.29)
project(Game)

# Set the C++ standard version
set(CMAKE_CXX_STANDARD 20)

# Include and link directories for Raylib (in ./libs folder)
include_directories("./libs/raylib-5.0_linux_amd64/include")
link_directories("./libs/raylib-5.0_linux_amd64/lib")

add_executable(Game main.cpp)

# Link dynamically to Raylib 
# Comment this if you are going with static linking
target_link_libraries(Game PRIVATE raylib) 

# Uncomment the following line if you prefer static linking
# target_link_libraries(cppray PRIVATE raylib.a)

Key Points:

• include_directories: Adds headers for Raylib.

• link_directories: Adds the path to the Raylib library files.

• target_link_libraries: Specifies whether you’re linking dynamically or statically (toggle as needed).

Revisiting the Previous Approach

In the first post, I used target_link_libraries(Game raylib) without specifying local paths, assuming a system-wide installation. While that approach is simpler, linking libraries from subdirectories can be more portable, especially for sharing projects or working across different environments.

The Vim and Emacs Journey

I started using Vim around 2017 and absolutely loved the modal editing and the fact that I could do everything right from the terminal. It felt almost like a superpower! But then, around 2022, I got curious about Emacs. For a while, I was all in. Emacs has some fantastic features—like compilation mode, Dired (the file manager), and Magit—that really stood out to me. Plus, it’s fully keyboard-driven without the complexity of Vim’s modal editing. Yes, I said it! While I totally get that modal editing in Vim is super efficient, it’s not the only way to edit text. After switching to Emacs, I found myself really enjoying non-modal editing a lot.

But here's the thing: I kept going back and forth between Vim and Emacs because, as much as I loved Emacs, it wasn’t perfect. For starters, its community is a lot smaller than Vim's, which made it tough to get some niche JavaScript tooling working. For example, getting LSP set up in Yarn PnP projects was a bit of a battle. But let’s not dive into that too much! I managed to set everything up, but it was a bit of a struggle and not exactly a pleasant experience.

Through all this, I realized that non-modal editing actually suits me better. That’s one of the reasons I kept gravitating back to Emacs, even though things weren’t always smooth sailing.

Is Emacs Really That Bad?

Sure, there are some downsides to Emacs. The smaller community means certain tools don’t have as much widespread support, but it really depends on what you're using it for. For example, there's a stronger Emacs community for languages like Common Lisp, Racket, Haskell, etc. So if you're working with those technologies, Emacs might just be the best choice, honestly.

Why I Switched to VSCode

Don’t get me wrong; I enjoyed customizing my setup in Vim and Emacs, but I didn’t want to go back to Vim because I’m just not a fan of modal editing anymore. So, I decided it was finally time to give VSCode a shot. I added Sublime keybindings (which I loved before my Vim days) and sprinkled in some of my own keybindings inspired by Emacs.

With VSCode, things just work. I’m using those Sublime keybindings, and the few tweaks I’ve made make it feel just right. It’s nice to have something functional right out of the box.

Now, that’s not to say VSCode is perfect. It’s not fully keyboard-driven like Emacs, but honestly, I’ve come to appreciate using the mouse when I need to. Plus, the modern UI is pretty nice—I didn’t think I’d care about that, but it’s grown on me.

Looking Back at My "Vim to Look Cool" Post

Reflecting on my old post about learning Vim to look cool, I can say that switching to VSCode now isn’t about looking cool or following a trend either. I’ve just shifted to what works best for me right now. Every editor has its strengths and weaknesses, and what really matters is finding the one that helps you be productive and enjoy your work.

Exploring Other Options

I tried Zed, and while it’s interesting, I just don’t feel like it’s ready for prime time use yet, at least for me.

I’ve also thought about WebStorm. I’ve used it in the past, and it was a great IDE, but since I dabble in multiple languages for fun, I need something that works across the board. To do that with JetBrains tools, I’d have to pay for the whole suite, and while I’m fine with paying for WebStorm, I’m not exactly eager to shell out for the entire package. So, for now, that leaves me with VSCode.

And honestly, VSCode isn’t that bad for me after all. It works with minimal effort on my part; it’s mostly about installing a few plugins. Plus, those Sublime + Emacs-inspired keybindings are pretty nice. Sure, it’s not as keyboard-driven as Emacs, but it works for me at the moment.

Looking Ahead

Who knows where I’ll go from here? Will I switch to WebStorm? Will I find a way to love Vim’s modal editing again? If that happens, I’ll probably install one of the Vim extensions for VSCode since I really appreciate the low configuration required now.

One thing is for sure: I’ll keep using tools that I enjoy and that inspire me to keep doing what I love, which is writing code.

usually what happens is when you install some package, Emacs modifies your custom-set-variables block to include the newly installed package in the package-selected-packages variable. But this does not anything special to install these packages on a new system (as far as I know). So when you are on a new system you still have to manually install all the packages present in this block to get your Emacs running without any issues.

So I wrote a script that I can just run on a new system which would read the package-selected-packages variable and install all the relevant packages for me.

Let's go over how to get this set up.

Step 1: have a separate custom-file

Add the following to your Emacs config to make sure the auto-generated custom-set-variables block is saved to a separate file.

(setq custom-file "~/.emacs.d/custom.el")
(load custom-file)

Step 2: Create the eslip script to do the package installation

Create a file called sync.el in your Emacs configuration folder with the following contents.

(require 'package)

(load-file "~/.emacs.d/custom.el")
(print package-selected-packages)
;; Add melpa
(add-to-list 'package-archives
             '("melpa-stable" . "https://melpa.org/packages/") t)

(package-initialize)
;; refresh packages
(setq my/package-refreshed-p nil)
(defun my/refresh-contants ()
    (unless my/package-refreshed-p
      (progn
    (package-refresh-contents)
    (setq my/package-refreshed-p t))))

(dolist (pkg package-selected-packages)
  (condition-case err
      (progn
    (let ((pkg-name (symbol-name pkg)))
      (eval (if (package-installed-p pkg)
            (print (concat pkg-name " already installed!"))
          (progn
            (print  (concat  "Installing: " pkg-name))
            (my/refresh-contants)
            (package-install pkg))))))
    (error
     (message "Failed to install package: %s. Error: %s" pkg err))))

This script will go through all the packages listed in package-selected-packages and install any that aren’t already on the system.

The key thing here: we don’t call this script during regular Emacs startup. That means package-refresh-contents is never called when Emacs is starting up normally. So no extra load times! You only run this sync.el script when setting up a new system or installing your packages. The rest of the time, Emacs stays fast as usual.

Step 3: Create a shell file to run the elisp script without launching Emacs

• Create an empty file with the following contents for example in ~/.emacs.d/sync

#!/bin/bash
emacs -q --script ~/.emacs.d/sync.el

• Make it executable:

$ sudo chmod +x ~/.emacs.d/sync

That’s it! Now, running ~/.emacs.d/sync will install any packages listed in your custom-set-variables block.

Conclusion

This technique is actually inspired by Doom Emacs. Alternatively, you could use use-package with :ensure t to handle package installation automatically. But honestly, I find that approach makes your config pretty beefy when you have a lot of packages. Adding a use-package block for everything feels clunky. And yeah, it might avoid the need for this script, but I like the simplicity of just listing the packages and not having to write a bunch of boilerplate.

This setup works perfectly for me—it's lightweight, avoids the usual slowdowns, and gets my Emacs ready in no time!

This blog post is not to say that Rails is bad or anything like that.

I recently got really inspired to give Ruby a real try after watching an interview and some talks by DHH, the creator of Ruby on Rails. In those talks, he shares how much joy he finds in programming with Ruby. I can totally relate to things he says, like “a text-editor-friendly programming language (no IDE required)” and “programming for the sheer joy of programming”, etc.

So, I wanted to give Ruby a real shot and started the “Try Ruby” tutorial on the official Ruby website. Midway through the tutorial, I got curious about what it would take to do some web programming with Ruby. I ended up discovering how to build a simple web server using Ruby. Below is the simplest web server implementation in Ruby, so future me won’t have to ask some AI about this again.

The simplest hello world web-server

require 'webrick'

# Define the server and specify the port
server = WEBrick::HTTPServer.new(Port: 3000)

# Define a main route
server.mount_proc '/' do |req, res|
  res.body = 'Hello, world!'
end

# Ctrl+C to shut down the server cleanly
trap 'INT' do
  server.shutdown
end

# Start the server
server.start

One step further: Using erb templates

require 'webrick'
require 'erb'

server = WEBrick::HTTPServer.new(Port: 3000)

# Define an ERB template
template = <<-HTML
  <html>
    <body>
      <h1>My name is <%= name %>!</h1>
      <p>The current time is: <%= Time.now %></p>
    </body>
  </html>
HTML

server.mount_proc '/' do |req, res|
  # Define variables for the ERB template
  name = "Bmax"

  # Render the ERB template with variables
  renderer = ERB.new(template)
  res.body = renderer.result(binding)

  # Specify content type as HTML
  res.content_type = 'text/html'
end

trap 'INT' do
  server.shutdown
end

server.start

Final step: Using external erb template

# server.rb
require 'webrick'
require 'erb'

server = WEBrick::HTTPServer.new(Port: 3000)

index = File.read('index.html')

server.mount_proc '/' do |req, res|
  name = "Bmax"
  renderer = ERB.new(index)
  res.body = renderer.result(binding)

  res.content_type = 'text/html'
end

trap 'INT' do
  server.shutdown
end

server.start

<!--index.erb-->  
<html>
    <body>
      <h1>My name is <%= name %>!</h1>
      <p>The current time is: <%= Time.now %></p>
    </body>
  </html>

Following is the link to the original stack exchange post:

https://emacs.stackexchange.com/questions/37918/how-to-highlight-graphql-template-literals-gql-in-jsx-files

step1: Install the packages

M-x package-install RET graphql-mode
M-x package-install RET mmm-mode

step2 : Put this in your config

;; Graphql
(require 'graphql-mode)
(require 'mmm-mode)

(mmm-add-classes
    '((js-graphql
          :submode graphql-mode
          :face mmm-declaration-submode-face
          :front "[^a-zA-Z]gql`" ;; regex to find the opening tag
          :back "`"))) ;; regex to find the closing tag
;; mode in the next line can be any major mode that you use for the particular file
;; The original answer from stackexchanged had js-mode,
;; I have replaced it with web-mode is that's what I use
(mmm-add-mode-ext-class 'web-mode nil 'js-graphql) 
(setq mmm-global-mode 'maybe)
;; Optional configuration that hides the background color for a highlighted block
;; I find it useful for debugging emacs, but when actually coding I dont want so much emphasis on submodes
(setq mmm-submode-decoration-level 0)

If you prefer to see these tips in action, check out the video linked at the end of this post!

Using :find for Fuzzy Searching

By default, the :find command in Vim requires the full path of the file you want to open. For instance, you might type :find src/parser/parser.odin.

Here’s a handy trick: if you set the path option to **, Vim will search through all directories from your current working directory. You can do this by adding the following line to your .vimrc:

set path=**

With this setting, :find becomes much more flexible. For example, if you type :find par and hit Tab, Vim will suggest files that match “par” anywhere in your directory. It’s a simple way to perform fuzzy searches without extra plugins.

Navigating Buffers with :buffer

To switch between open files, you can use the :buffer command (or just :b). Suppose you have these files open:

• src/parser/parser.odin

• src/main.odin

• src/tokenizer/tokenizer.odin

Typing :b to and pressing Enter will take you to the buffer that matches the input. In this case it’ll open the src/tokenizer/tokenizer.odin file. It’s a straightforward method for navigating between your open files.

Enjoying the Simplicity

As I started using these built-in commands more, I found them to be quite effective. They offer a simple and efficient way to search and navigate files and buffers without relying on additional plugins.

Vertical Completion Menu

If you prefer a vertical completion menu, similar to what you might see in Neovim, you can enable it in Vim by setting wildoptions to pum. Unlike Neovim, this isn’t the default in Vim. Add this to your .vimrc:

set wildoptions=pum

Conclusion

Exploring Vim’s built-in file finding and navigation features has been a rewarding experience. By adjusting :find and using :buffer, you can navigate and manage your files effectively with just the default tools.

You can see these techniques in action in the video below.

Happy Vimming!

You don't need to install Arch Linux on your laptop or buy a new laptop or install it on a vm to try window management development. Xephyr is just enough for testing the basics. Just make sure you press Ctrl + Shift to lock focus when trying to do any binding in the window manager been tested.

The most basic command to start the window manager in a nested session is to do something like

startx i3 -- /usr/bin/Xephyr :1
# with specifying window size
startx i3 -- /usr/bin/Xephyr -screen 800x500 :1

just make sure to use the full path to the Xephyr.

Above method works, but most of the times when you are just starting out you may not have a way to launch apps inside the window manager. For that using a keybinding agent like sxhkd will be very useful. To do that we need to be able to run other programs besides the window manager while launching.

To do that we can use a xinitrc to add the programs we need to launch.

so we can create a xinitrc file with the following content.

sxhkd ~/.config/sxhkd/sxhkdrc &
xterm & # also launching a terminal just in case
# assuming the window manager
# executable is called main and is in the current directory
exec ./main

then you can also have another script to call xinit and open Xephyr with the relevant options

#!/bin/sh

set -e
#!/bin/sh

set -e
make # just calling make to build the project once more,
# so we can just use this one script to just build and run
XEPHYR=$(which Xephyr)
xinit ./xinitrc -- \
    "$XEPHYR" \
    :100 \
    -ac \
    -screen 800x500 \
    -host-cursor

Useful links:

https://cs.ossu.dev/

https://github.com/ossu/computer-science

https://ossu.firebaseapp.com/#/

I have always been a fan of touch typing and exploring different keyboards, layouts, etc.

I learned how to touch type in QWERTY around 2006-2007 and used a bunch of online tools back then too.

I currently use Dvorak as my main keyboard layout, and my typing speed varies between 60 to 70 on most online typing tests. I can reach around 90 if I reduce the time or the number of words for a test down to 10, but that's not really what I want.

However, there are a lot of people who can type past the 100 WPM mark. I once asked somebody what the secret to getting really fast at typing was. They said something like, "think of a word you can type really fast already. Type it really fast - muscle memory, like a roll of ASDF. Apply this feel to a bunch of more words," which totally makes sense.

So, I started my mission to increase word speed, and to do that, I wanted some custom features for my typing practice apps. What better way to do that than writing my own, right? :)

I kept thinking about the logic for displaying a typing test interface for something similar to MonkeyType. In the shower, it hit me. I cracked the code, went back to my laptop before bed, and started writing some code. I got the basic typing test display working in about 1 or 2 hours. The next morning, before work, I added indicators for words per minute and test duration, and I already had something usable.

That night, I added a settings page which only supports changing the word count. This was also an important feature I wanted. It allows reducing the word count down to one word, so I get to measure my WPM on a more granular level and identify where I struggle.

I still don't have all the features I want, and it's not finalized by any means. But I'm really happy about having a small side project like this that I can keep improving bit by bit, every now and then. So, I hosted it under a subdomain (type.imbmax.com) for now.

sudo apt-get install postgresql-client

Next, you need to find the IP address of the Docker container running PostgreSQL. You can do this by running the following command:

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container_name>

Once you have the IP address, you can connect to the PostgreSQL instance using the psql command. Run the following command in your terminal:

psql -h <ip_address> -U <username> -d <database_name>

Follow these steps to create a new dune project if you don't already have one.

• First, initiate the project structure.

    dune init project foo
  

• It will create a project structure like this

• 

  The bin folder contains the source file for the main executable main.ml

• the bin/dune file has the build instruction for the executable, it'll look something like this.

    (executable
     (public_name foo)
     (name main)
     (libraries foo))
  

Adding Support to build multiple executables

• Let's see how to add support to build another executable called bar, which we'll write in the file called bar.ml.

• First, create a file called bar.ml in the bin directory.

• Then you can update the bin/dune file support multiple executables like below.

    (executables
     (public_names foo bar)
     (name main bar)
     (libraries foo))
  

Build and run the different executable

You can use the following commands to run the different executables.

dune exec ./bin/main.exe
dune exec ./bin/bar.exe

To build you can run following

dune build ./bin/main.exe
dune build ./bin/bar.exe

To run the built executables

 ./_build/default/bin/main.exe
 ./_build/default/bin/bar.exe

You know how you can use "/" and "?" to perform forward and backward searches for text in the current buffer. Similarly, in Emacs, you can use Ctrl+s and Ctrl+r to search back and forth. There's a slight difference in how it works in Emacs, though. In Emacs, searching starts immediately as you type Ctrl+s, and the text you type is incrementally added to the current search term. You can achieve the same behavior in Vim with "set incsearch," but there's more. In Emacs, you can keep hitting Ctrl+s and Ctrl+r to continue searching back and forth in the buffer while still editing the search term.

Can we do the same in Vim?

Yes, you can, but it works slightly differently in Vim. When you are in incsearch mode, i.e., once you hit "/" or "?" and start typing a text, you can still edit the text and search back and forth without having to go back to normal mode. The default keys to do that are Ctrl+g (search forward) and Ctrl+t (search backward).

However, this might be a lot to remember, and you may not end up using it even though you know it because of all the keybindings you have to remember.

I have a simpler way to achieve this in my configuration, where I'm able to use Ctrl+s just like in Emacs. Instead of Ctrl+r, I mapped search backward to Alt+s because Ctrl+r is the default keybinding to redo.

The following is what I have in my Neovim config to make this work:

vim.keymap.set('n', '<C-s>', '/')
vim.keymap.set('c', '<C-s>', '<C-g>')
vim.keymap.set('n', '<A-s>', '?')
vim.keymap.set('c', '<A-s>', '<C-t>')

I will list down few techniques with some use cases.

Use case one: Find and replace a dependency version in multiple package.json files in a monorepo.

Imagine you have a monorepo containing multiple Node.js packages, each with its own package.json file. You want to update the dependency version of "foo" from v3.5 to v4.0 in all package.json files. To achieve this, you can use the following command:

:args ./**/*package.json
:argdo %s/foo-v3.5/foo-v4.0/

The args command sets the argument list to the specified files, and the subsequent argdo command runs on each file in the argument list. The argdo %s/foo-v3.5/foo-v4.0/ command performs a global search and replaces within the current file, replacing "foo-v3.5" with "foo-v4.0".

This technique is useful when you know all the files that need modification beforehand, as it can be more efficient than the technique used in the next use case.

Use case two: find and replace a term any term in multiple files

Suppose you want to replace all occurrences of "foo" with "bar" in all TypeScript files under the "./src" directory.

:grep foo ./src/**.ts
:cdo %s/foo/bar

The grep command searches for the specified pattern in the specified files and outputs a list of matching lines. The subsequent cdo command operates on each line in the list and runs the following %s/foo/bar command. This performs a global search and replace within the current file, replacing "foo" with "bar".

This technique is useful when you don't know all the files that need modification beforehand or when you want to apply changes to specific lines or patterns within files.

In addition to these techniques, Vim offers many more powerful commands for working with multiple files simultaneously. By mastering these commands, you can greatly enhance your productivity as a Vim user.

Error: listen EADDRINUSE: address already in use 0.0.0.0:3022

Okay, so the port you need is already in use. Now what? You decide to ask some AI chatbot for help, hoping it can quickly point you in the right direction.

You type in something like:

"Hey robot, how do I find out which process is using a specific port in Linux? I'm getting this EADDRINUSE error for port 3022."

And sure enough, the bot does its thing and gives you a simple, clear solution:

Step 1: Find the Process Using the Port

Open up your terminal and run:

$ sudo lsof -i :3022

This command lists all the processes using port 3022, along with their Process IDs (PIDs). Now you've got the culprit!

Step 2: Kill the Process

Once you have the PID, freeing up the port is as easy as:

$ sudo kill -9 <PID>

Just replace <PID> with the actual number from the previous command. If you're not sure about killing a process, you can always try restarting your system or changing the port number your application is trying to use.

With this quick fix, you're back in action and ready to continue your work. Sometimes, a little nudge in the right direction is all you need to solve these annoying little problems.

Closing Thoughts

Running into port conflicts can be a bit frustrating, especially when you’re in the flow of coding. But with a couple of terminal commands, you can easily resolve the issue and get back to what really matters—building and creating. So next time you hit this snag, remember this quick trick!

I have tried many tools and techniques to track time. Tracking time helps me organize a bit better and manage my time better. I have tried things like spreadsheets, and different utility Apps, but nothing stuck for more than a couple of days.

The good news is since I switched to Emacs recently, it opened me up to the world of org-mode, which has been pretty useful lately. But before getting to the good stuff I'll list down some of the stuff that I've tried in the past. And as with everything I wanted something keyboard-driven because I like it that way :)

Tools and techniques I've tried in the past

Spreadsheets

Spreadsheets was a no-brainer, it was simple enough for the job. I used to just add the list of tasks and added start and end times on two columns and at the end of the day, with the help of a few formulas, I was able to see stuff like time spent on different tasks and the total time, etc.

This was fine but wasn't perfect.

Project hamster GTK timetaker

This was a good app, but it only runs on Linux, but I needed something cross-platform.

Manual text or Mark-down files

This was a perfect solution for my itch for using the keyboard, because this, I can do in my editor. But the downside is that, text files can't really do more than just holding onto what I put in them, thus, no easy way to calculate times. End of the day I had to use a spreadsheet again to do the calculations and there's no way to quickly check the time I've spent on the current task.

Here comes the Org Mode

So now I'm on Emacs, I've heard all the good stuff about org-mode, but soon I found out that I haven't heard it all :). My plan on capturing times on org-mode was to have an org table and insert times on that and figure out how to do calculations on org tables and you know the drill. But this was a very naive attempt at using org-mode for tracking time and I hated it. After trying that, I knew there were only two ways it was going to end up: either all the buzz about org-mode managing your life stuff is made up, emacs fan-boy stories, or I didn't know enough. Luckily it turned out to be the latter :).

Time tracking for real in Org Mode

So I watched a few more YouTube videos and figured how it's done. I discovered the Org clock which was the real deal, it allows to clock in and out on org-mode document items.

Here's how I use it:

• Add the beginning of the day, I create a list of tasks I'll work on that day on a new org file.

• Then as I start each task, I just take the cursor over to the tasks name then call org-clock-in ( which is set to SPC m c i in Doom emacs )

• Every time I clock in, it just adds a new click entry to the current task and adds an end entry to the previously active clock entry.

• And I create add a clock report at the top of the org file calling org-lock-report. The report shows a summary of time spent on each task.

A sample org file with time tracking and clock report:

This actually fits really well in my workflow, I'll list down some of the pros below.

• It's Emacs all the way Having time tracking inside my editor mean no switching between multiple Apps, and no new key bindings to learn. I can just treat my time tracker as another text file and edit anything on it using the same musle memory I use for any other editing.

• No more manual counting

Although it's just a text file, org-mode give these features like real-time status, at any given time I can see the total time I've spent on the current task on the mini buffer. And there is also org-update-all-dblock macro, which updates all the org-clock-report(s) that's in the current buffer (yes, the report is not real-time, need to run that macro to update, but hey it's just one macro, no drama!! 😊)

So is this it? is it the ultimate time tracker?

Well, this is the technique or tool which I stuck for this long. It's been two weeks now since I've started using it and it's been the most satisfying time tracker I've used till now. No big complaints here, as I said, it fits nicely within my workflow, but I wished the report was more autonomous, also I wished if there was a little bit more ease in clocking in and out. I mean, I could set a different key binding for that, but what I'm trying to say is, the overall experience could improve a bit more.

Do I recommend it to everyone?

Yes and No!!, I mean if you are already using Emacs, I don't have to recommend it, you might already be using it or maybe something better than that, but if not, I highly recommend giving it a shot. But I don't recommend it for non-Emacs users. I think learning Emacs just to use the org-mode time tracking feature is a big undertaking, which may not be worth of your time (well, depends on your own valuation of time :) ), and it won't be satisfying either, because you have no other use of Emacs :). It's perfect for me (at least for now), because I'm using Emacs as my editor.

Also, I'm now back on Neovim, after using Emacs for a full year, I might write a follow-up post sometime later.

TLDR:

I was happily using vim (neovim), then one day I discovered Lisp,
a week later I switched to Emacs

I had been using Vim since 2017. At first, I had vscode as a backup for when I had to do some major code refactoring, but around mid-2020, I decided to go fully Vim and never turned back, until one day…

A Vim Confession

Although I had been using Vim to a religious level, I felt the need for something more rich from time to time. Following are some of the pain points I had with it.

• No proper GUI

Now don't get me wrong, I don't enjoy clicking around with the mouse all day, I want to keep using the keyboard as my primary input device, but we keyboard lovers mostly end up spending most of our time on the terminal emulators because there isn't much GUI software built with the keyboard in mind. I think that's where things have gone wrong, GUI doesn't mean we have to lose the convenience of doing things with the keyboard. I use a lot of terminal-related utils, but I fancy a nice Gui version of Vim.

• Viml and Lua

Yes, vim and Neovim have bindings for a lot of languages for plugin development, but to do basic config stuff you need to deal with either vim or Lua. Yes, lua is simple, it's easier to understand and write, but I just don't enjoy Lua much.

Vim Emulation on other editors

In the past, I have tried a few other editors/IDEs with vim emulation, like vs code, web storm, and sublime. For the most part vim style editing works fine but as soon as I try to work with multiple files, I'll have to go back to using the mouse at some point, which I don't really enjoy while writing code.

The main reason for that is the fact that unlike Vim none of those editors were built to operate with just a keyboard. But I always knew there was this other editor which was keyboard-driven just like Vim, more on that later.

Trying Emacs

So if other editors don't cut it, it must be Emacs right, emacs was built with the keyboard in mind, it came around the same time as Vim. Also, I have heard all the stories about people switching to Emacs because of how awesome org-mode was or Magit (a popular git client implementation on Emacs), but I also none of that is going to make me use Emacs if it can't give me the same experience while writing code. So I thought I'd give it a try.

I have tried Vanila Emacs and its built-in tutorial before, but I never liked the default keybindings that came with it. I also didn't want to spend a lot of hours in Emacs to learn how to configure. I have heard of these prebuilt distributions of Emacs, I wanted to try one of those to see if Emacs can do what I want. If it works then I can learn how to config it later.

Two major such distributions I've heard of were Spacemacs and Doom. I didn't like the layer system in Spacemacs, so I decided to try Doom Emacs.

Immediately after trying it I had these issues:

• Doom emacs was slow to me compared to Vim.

• I still need to configure stuff to get it to a usable state for my taste, Evil mode (vim emulation) was good but it wasn't perfect.

• File navigation

On Vim I just use Netrw to go into nearby files, I used "-" to open it and use j, k, h, l to navigate through it (this is not the default behavior, I had my Vim configured that way). But I just didn't know who to make Dired (Emacs's default file browser) to do that.

After a few hours of trying Doom Emacs, I wasn't interested enough in going further with it, because I wasn't that impressed with performance or Elisp (the language used to configure Emacs).

So I decided that Emacs wasn't for me, part of me secretly still wanted to try Emacs, but my weekend was over, and I didn't want to spend any more time on it, then I turned back to Neovim, vim is the best editor in the world.

The Story

As a programming language enthusiast, I spend a lot of time learning about different languages, maybe more time than I really should. So, I have come across Lisp many times, but it was something I was never interested in because I always thought it was just some set of languages only used at some abstract mathematical theory level.

Fennel

My first encounter with Lisp in action was watching vim conf 2019, I saw this language called Fennel, a Lisp that compiles to Lua. It can be used to configure Neovim, basically, it can be used in any place where Lua can be used. That was interesting but I didn't try it because it was lisp

Finally, trying out Fennel

On a one fine Sunday evening, I just thought of finally checking out Fennel, just because I was fed up with Lua, and I wanted to give a refresh to my Neovim config, I thought I'd try this Fennel lisp thing to see how far it goes, (hint: lisp did came very far although fennel didn't ).

So I started to explore a little bit of fennel side-by-side with Lua. I started writing stuff in Fennel and watching the Lua output on a second split of my editor. To this date, I can't articulate the feeling I got as I was watching that process. I was amazed by how I was able to generate so much lua with very little fennel, and very little syntax. If you know Lisp, you know there's not much syntax to it, it's just mostly all lists, but the output on the Lua side was ugly, no blame on the compiler, it's just what Lua is, it's not pretty in my eyes.

Exploring more about Lisp

After being marveled by watching Fennel, I wanted to find out more about this Lisp thing, so I went on youtube and started watching a lot of videos on Lisp. One of the talks I watched referred me to this other talk called Simple made easy by Rich Hitchkey the creator of the Clojure programming language. I kind of bought into what he said in that video, "Simple constructs make it easy to build better solutions" (this may be not what he exactly said, but something around that, at least that's how I understood it).

So with this new mind said when I look back at lisp, I felt it, I felt that since lisp is so simple, maybe it makes it for crafting better software. And then I also thought about these stories about how Emacs has better packages (the equivalent of plugins in Vim world) compared to the similar counterparts in Vim. And even there have been innovative things like org-mode, which only first came in the Emacs world. And then I saw some more non-Emacs stuff that was built with Lisp.

It was still that same Sunday I rediscovered fennel, and I couldn't sleep well that night, I had a lot of lisp dreams, I was going to try all these new lisp stuff next weekend. There was suddenly a lot I wanted to try and find out more about, things like more fennel, Clojure, Clojure script, Common Lisp, and a big endless list of stuff.

Trying Doom Emacs again

The next week I kept watching more youtube videos on Lisp in the evenings, and because a lot of Lisp programmers use Emacs, I saw a lot of Emacs stuff too. By around Thursday, I couldn't resist the urge to try Emacs again. And I tried it, this time though, I was fully armed to write some lisp, and I was able to configure Dired to work similarly to how Netrw worked in my Vim configuration.

Dired configuration:

;; binding for going up a directory with "h" in dired
(map! :map dired-mode-map :n "h" #'dired-up-directory)
(map! :map dired-mode-map :n "l" #'dired-find-file)

(after! dired
  (map! :n "-" 'dired-jump))

;; show simple list without the all the ls -al stuff
(add-hook! dired-mode
    (dired-hide-details-mode))

That was it, that's all the Elisp code I had to add to get Dired to behave the way I wanted it to, this was pretty straightforward, I know I'm using the doom emacs macros, but it gets the job done. By this time I was pretty impressed by the fact that I was just able to configure emacs to be more like I needed it to be.

So I decided to spend that evening playing a bit more with Emacs and coding a bit more to see what was missing, after hours and about a few more lines of Elisp, I had Doom emacs working, very similar to my tmux + vim setup.

But wasn't Doom emacs slow?

I didn't care anymore, I existed in this new lisp-driven environment, and I didn't want to lose it. Yes, it took like a few more milliseconds to open a file sometimes, but not all the time, but with that and a few lines of configuration I was getting a lot more.

In Conclusion

In the past, I was running away from emacs because of Lisp and also because I was so in love with Vim. But Lisp got me chasing behind Emacs this time around. And now I'm also using all the other good stuff which came with Emacs. I'm using Magit for most of my git work. I'm becoming an org-mode junky. I'm tracking my time on it, taking my notes on it, and even writing this blog post on an org file. And also, I'm working on my own Emacs configuration on the side as I find time so that I don't have to depend on Doom config.

Is Emacs the best text editor in the world now?

No!!, In my opinion, that place is still for Vim, then why Emacs? because Emacs is overall a better software and an extendable interactive development environment, yes, by design, it's made for extendibility. I'm still using Vim key bindings for almost all the editing I do inside Emacs. I have even mapped Ctrl+u to do page up, but I think that's a big no-no in Emacs world because Ctrl+d has some special meaning in Emacs, I may or may not change that in the future, but that's what I have for now.

So was Vim a mistake? would it have been better if I had started with Emacs itself?

I don't think so, as I said, figuring out how to get productive with Emacs was a bit hard at first. I don't think I'd have taken this big of a leap if I hadn't started with Vim to begin with. So I'm glad I started there.

This is it!!

I can write this post forever and never publish it, so I'm going to end it here, I'll write more about this new experience in the future.

I used to use gnu make by writing my Makefile(s) by hand, and I have tried a little bit of premake which is a build system written in Lua. I knew that cmake should be the easiest solution, but I always found it very intimidating to learn how to use cmake.

So here's the simplest cmake file you can create.

(this content should go into a file called CMakeLists.txt)

# Specify the minimum version of cmake to use
cmake_minimum_required(VERSION 3.0)

# Specify the name of the executable
project(Game)

# list all the source files next to the executable name
add_executable(Game main.c)

# Add this line if cmake complains about not being able to find your library (in this case raylib)
find_package(raylib)
# Add any external dependencies
target_link_libraries(Game raylib)

you can build your project in a build folder by issuing the following commands in the terminal.

$ mkdir build
$ cd ./build
$ cmake ..
$ make