DEV Community: HitBlast

Unlocking the bootloader of Xiaomi's HyperOS (v1)

HitBlast — Sun, 26 Oct 2025 02:38:04 +0000

About this blog

I have recently moved to my personal blogfolio for posting articles.

Read the original article from here.

How I configured the Zed editor for daily-driving

HitBlast — Fri, 15 Nov 2024 17:33:47 +0000

Some backstory

Okay, to be honest, most of the people who start off with programming choose Visual Studio Code as their primary editor of choice. It’s not unknown that the editor itself has gathered enough reputation and appraisal in the development community for its modular architecture, “lightweight” experience and the use of extensions to turn it into a full-fledged IDE.

However, like most other apps primarily built on top of web technologies, Visual Studio Code, or VSCode, uses the Electron framework as a building block for its codebase to serve the editor experience through Node.js, which again, is definitely not the fastest experience on the market.

In fact, in my 6 years of working on different programming projects and ideas, although Visual Studio Code has been at the top of convenience, it has also been one of the slowest text editors I’ve ever used.

Zed as an editor

Recently though, I’ve forced myself out of the garden wall of VSCode and onto many other text editors as a way of learning new approaches to coding. I’ve started working with Vim motions, and I know it will take a few months to get used to, I’ve found the perfect editor for my use case as a multi-language programmer - Zed.

I mean - my first impression with Zed was with the response time it took to just “boot up” on my working laptop. The difference was really staggering when it comes to VSCode turning on with all of the extensions for C, Rust, Python, Flutter and what not - versus Zed, with all the same things but while also feeling a ton lighter.

A thing to note beforehand

All of the written materials which have been presented in this article are available in this configuration file on my GitHub so that you can check it out after reading. Now that we are done with the initials, let's get going!

Setting things up…

As show above in the image, I like quite a few “personal” touches on my editor experience, and Zed makes it very easy to do with the JSON configuration scheme.

First of all, let’s open up a terminal window and write these commands to ensure our environment is good for modification:

# Make the configuration directory for Zed.
$ mkdir -p ~/.config/zed

# Create a new `settings.json` file.
# This is where our configuration will reside.
$ touch settings.json

Now we can open the newly-made file in our preferred editor. I’ll choose vim for this instance:

$ vim settings.json

Primary configuration

In order to replicate the exact window as the image, let’s ensure that all of our panels are in place. To do this, let’s write the following code first:

{
  "notification_panel": {
    "dock": "left"
  },
  "chat_panel": {
    "dock": "left"
  },
  "outline_panel": {
    "dock": "right"
  },
  "project_panel": {
    "dock": "right"
  }
}

This will dock all of the panels (notification, chat, project outline & the primary project panel) in their respected positions.

I also like to disable sending telemetry data for all of my apps. Now if you like to do that too, paste this code, otherwise it’s just personal preference. :p

{
  ...
  "telemetry": {
    "diagnostics": false,
    "metrics": false
  }
}

Now we’re entering hot waters. A core part of coding is seeing our preferred font family in action - every, single, time. I’ve chosen the JetBrains Mono font as the primary monospace font here as I quite like their overall accent. We can use this code to setup our font:

{
  ...
  "ui_font_family": "JetBrains Mono",
  "buffer_font_family": "JetBrains Mono",
  "ui_font_size": 16,
  "buffer_font_size": 13,
}

While also setting the font family - I also like to set up Vim Mode for all of my code editors. Since I’m more of a Vim “motions” user rather than just the plain Vim editor, I enable this feature for all the supported IDEs in order to make myself write code fast. I also set the keybinds to be identical to that of Visual Studio Code’s. So, Inside the configuration file, I would do something like:

{
  ...
  "base_keymap": "VSCode",
  "vim_mode": true,
}

I also set up relative line numbers in order to quickly navigate between lines using the Vim motions. To do this, simply write the following code afterwards:

{
  ...
  "relative_line_numbers": true
}

Advanced Configuration

Now that we’re done with the basics of configuring Zed from above, let’s move on to some more “head-on” stuff with the core utility of the editor itself.

Firstly, I always prefer to save the extensions in one way or another when I’m using a code editor. As a Flutter / Rust / Python developer, I use the extensions with the given identifiers below for my current setup:

// Automatic extension installation
{
  ...
  "auto_install_extensions": {
    "dart": true,
    "git-firefly": true,
    "ruff": true,
    "xcode-themes": true,
    "toml": true
  }
}

This snippet will auto-install these extensions whenever you install Zed with the same account you use for synchronization.

Since I’ve also added the xcode-themes extensions (the color scheme of Xcode is my favorite), now I can activate it with the following configuration for themes:

{
  ...
  "theme": {
    "mode": "system",
    "light": "Gruvbox Light Soft",
    "dark": "Xcode High Contrast Darker"
  }
}

Oh, and, since I use Python in my everyday scripting as well, I’m often in need of virtual environments in order to run them. But, unlike Visual Studio Code and some other beginner-friendly IDEs, Zed does not come with prebuilt virtual environment initialization, but it is, however, manually configurable from the settings.json file, like this:

// Automatic workspace activation
{
  ...
  "terminal": {
    "detect_venv": {
      "on": {
        "directories": [".env", "env", ".venv", "venv"],
        "activate_script": "default"
      }
    }
  }
}

This ensures that whenever a terminal window is opened, Zed will automatically activate the virtual environment present in the current workspace.

In our final steps of configuring, I’d like to note that the tagline of the Zed editor itself says that it is a “next-generation code editor designed for high-performance collaboration with humans and AI”, and personally even though I don’t use much AI features as a developer, I do however appreciate the convenience it provides in some sticky situations. I also use GitHub Copilot if I’m on Visual Studio Code, so to configure it inside Zed with the GPT 4o Large-Language Model (LLM), we can do something like this:

{
  ...
  "assistant": {
    "default_model": {
      "provider": "copilot_chat",
      "model": "gpt-4o"
    },
    "version": "2"
  }
}

Wrapping it up

So that’s it. It has been almost a month since I have switched my complete development workflow from VSCode over to Zed, and I, ever since, have had one, “chef’s kiss” of a delight whilst traversing my various codebases with it. It’s a pleasant surprise for developers who are using Zed only for the performance and sheer customizability it provides - and it’s a fully worth-it experience for sure.

I’ll soon be writing about my language-specific Zed configurations since I found it really enjoyable to search and tweak it myself. Till then, stay tuned!

Managing dotfiles using GNU Stow on macOS

HitBlast — Mon, 04 Nov 2024 08:06:47 +0000

Backstory

As part of my journey with various stacks and technologies, I've encountered a common challenge: managing numerous configuration scripts and "dotfiles" in my home directory. This can be frustrating, as we often find ourselves resorting to the cp and mv commands more frequently than necessary.

Though I had my own personal dotfiles repository before, I essentially followed the conventional practice of "copy-paste," similar to many others. For instance, if I needed to update my .zshrc file for some reason, I would first update my configuration on GitHub using the following commands:

# opening dotfiles folder
$ cd ~/Developer/dotfiles

# modify the .zshrc file
$ code .zshrc

# copy the new configuration to home directory
$ cp .zshrc ~/.zshrc

# finally, push the changes to main branch
$ git commit -a -m "modified .zshrc" && git push origin main

As you can see, this is a lot of commands for doing so little. However, there's a great workaround to all of this.

`stow` to the rescue!

In order to install GNU Stow on your Mac, you need to have Homebrew first. Install Homebrew and all of its dependencies using the following command:

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Once installed properly, we can install Stow using the following command:

$ brew install stow

That's it! You now have stow on your machine. Now let's set things up for maintenance.

Using `stow`:

First let's create a new .dotfiles folder in our home directory. This is where we'll start moving all of our preexisting configuration to. To do this, simply use:

$ mkdir .dotfiles && cd .dotfiles

This will create the directory and change your current working directory to it. Now, the primary way the stow command works is by using symbolic links so that you don't have to create them yourself. Let's start by moving a file and seeing how stow works.

Let's move the .bashrc file that I have in my home directory into the dotfiles folder:

# move to current folder
$ mv ~/.bashrc ~/.dotfiles/.bashrc

After executing these, we can use the stow command like this:

# symlink all files in current directory
$ stow .

Now if you open Finder and look at your .bashrc file, you'll notice that it has a little "shortcut" icon next to it, which means that macOS has successfully recognized it as a symbolic link to your file and it'll redirect to it.

You can manually move all of your needed files into the .dotfiles and once everything is in place, run stow . again to reflect your changes in the home directory.

Removing stowed files:

If you want to, for whatever reason, undo the actions done by executing the stow command, simply cd into the .dotfiles directory using your terminal and run this command:

# deleting all symlinks
$ stow -D .

This will clear up all the symlinks which were previously created by the program.

Managing and preserving dotfiles

The best thing about stow is that, it can be used alongside a .git folder, as well as the typical Git configuration you'd do on a repository. Which means, a stowed folder acts exactly like a Git repository and a mirror of your home directory if you want it to.

First, we'll create a new .stow-local-ignore file and open it in Vim (you can use your favorite text editor for this):

# create the file
$ touch .stow-local-ignore

# open it in vim
$ vi .stow-local-ignore

Now, paste the following content into the file:

\.DS_Store

Often times, macOS creates these .DS_Store files for indexing (e.g. for use in Spotlight Search), and these will keep popping up in your folders. In order to circumvent this situation, we can use the file Stow uses to identify locally ignored files in order to avoid unexpected symlinks.

Now that we've done some basic cleaning, it's time to create a Git repository to commit your changes for preservation:

# create new repository and branch
$ git init && git branch -M main

# commit your changes
$ git add --all && git commit -m "stowed!"

Later on, you can create a Git repository on your preferred version control platform (GitHub / GitLab) and add a remote to this local repository in order to backup the files.

Voila!

Now you have a proper way to manage and interact with your dotfiles, directly using a simple command-line tool. You can check out my own interation of the following post in order to learn more about how the directory structure is managed by GNU Stow. Thanks for having a read! :D