Neovim

Background

Inconveniences with the current setup

I was using Neovim DAP with GDB for C debugging. Here’re some inconveniences during the debug process:

• needed fflush(0) for displaying standard output in the REPL (the small buffer below)
• Gemini’s suggested solutions for obtaining standard input sounded too complicated, like:

  • attaching GDB to an external TTY, or

  • from a certain file

    dap.configurations.c = {
      {
        name = "Launch with File Input Redirection",
        type = "gdb", -- or codelldb
        request = "launch",
        program = function()
          return vim.fn.input("Path to executable: ", vim.fn.getcwd() .. "/", "file")
        end,
        cwd = "${workspaceFolder}",
        args = { "<", "input.txt" }, -- Passes input.txt as standard input
      },
    }
    

Popularity of an alternative compiler

AI Learning Club’s C course’s introduction says that Clang often offers a quicker compilation and more informative error messages. As a result, I was feeling motivated to connect Neovim DAP to LLDB instead.

Accidentally triggering a destructive command is one of the worst feelings during daily development. Keybindings that alter remote branch history—like git push --force—should require deliberate intent so they aren’t hit by a stray keypress.

Inspired by a commit in thallada’s neovim-config, shifting keymaps for destructive operations from lowercase to uppercase (<Leader>gf → <Leader>gF) adds a crucial layer of friction.

The Problem with Lowercase Shortcuts for Destructive Actions

When mapping Git commands inside NeoVim, it is common to group them under a <Leader>g prefix:

Streamlining execution flow during an active debugging session requires fast, intuitive keyboard shortcuts. In commit ca95bed6 to my nvim-config repository, I added four custom keybindings to make evaluating expressions, managing conditional breakpoints, and terminating debug sessions much cleaner.

Here is a breakdown of the new additions to lua/plugins/dap.lua.

1. Floating Expression Evaluation (<Leader>de)

Inspecting variables on the fly without switching focus into the DAP UI panels keeps your focus on the code structure:

Refactoring code across multiple files or large codebases can quickly become error-prone when done via manual find-and-replace. Modern Language Server Protocol (LSP) integrations solve this by providing AST-aware symbol renaming across your entire workspace.

In this post, I will walk through my newly updated nvim-lspconfig configuration using lazy.nvim, mason.nvim, and native LSP keymaps like <Leader>rn for symbol renaming.

You can view my complete, live Neovim configuration on GitHub:

👉 VincentTam/nvim-config: lua/plugins/lspconfig.lua

Core Plugin Architecture

My LSP stack uses a clean, lightweight combination of three plugins:

Setting up the Debug Adapter Protocol (DAP) in Neovim transforms C and C++ workflows by integrating full-featured debugging—breakpoints, call stacks, REPL execution, and variable evaluation—directly into your modal editing experience.

Rather than maintaining static code snippets in this post, you can inspect my active setup directly on GitHub:

👉 VincentTam/nvim-config: lua/plugins/dap.lua

Core Architecture

The setup relies on three primary components managed through lazy.nvim:

• mfussenegger/nvim-dap: The foundational DAP client implementing protocol communication with native debuggers.
• rcarriga/nvim-dap-ui: Provides layout management, split frames, and floating windows for scopes, stacks, and watches.
• williamboman/mason.nvim: Handles system binaries and language tool installation.

Ergonomic Navigation: Shift + Arrow Shortcuts

While traditional DAP keymaps often use multi-key leader sequences (e.g., <Leader>dn), navigating execution during a active step-by-step session is much faster with single-key modifications.

Aujourd’hui, j’ai passé ma configuration de développement sur une VM Google Cloud Platform (GCP). Entre les contraintes de ressources de la machine et le peaufinage de mon environnement Neovim pour mon projet Rust, voici ce que j’ai appris.

1. Transfert de fichiers avec rsync

Pour uploader mes dossiers de projet vers la VM, j’ai utilisé rsync. C’est bien plus efficace que scp car il ne transfère que les modifications.

rsync -avzLP --exclude='.git' \
  ~/.local/share/typst/packages/preview/auto-mando/ \
  user@$(gcloud compute instances describe typst-bot-vm \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)' \
    --zone='us-east1-d'):~/

Le « combo doré » :