Hacker News

Claude Code IDE integration for Emacs

2025-08-0613:17782266github.com

Claude Code IDE integration for Emacs. Contribute to manzaltu/claude-code-ide.el development by creating an account on GitHub.

https://github.com/manzaltu/claude-code-ide.el/workflows/CI/badge.svg https://img.shields.io/badge/GNU%20Emacs-28--30-blueviolet.svg https://img.shields.io/badge/License-GPL%20v3-blue.svg

Claude Code IDE for Emacs provides native integration with Claude Code CLI through the Model Context Protocol (MCP). Unlike simple terminal wrappers, this package creates a bidirectional bridge between Claude and Emacs, enabling Claude to understand and leverage Emacs’ powerful features—from LSP and project management to custom Elisp functions. This transforms Claude into a true Emacs-aware AI assistant that works within your existing workflow and can interact with your entire Emacs ecosystem.

  • Automatic project detection and session management
  • Terminal integration with full color support using vterm or eat
  • MCP protocol implementation for IDE integration
  • Tool support for file operations, editor state, and workspace info
  • Extensible MCP tools server for accessing Emacs commands (xrefs, tree-sitter, project info, e.g.)
  • Diagnostic integration with Flycheck and Flymake
  • Advanced diff view with ediff integration
  • Tab-bar support for proper context switching
  • Selection and buffer tracking for better context awareness

This package enables Claude Code to leverage the full power of Emacs through MCP tools integration. Claude can directly access and utilize Emacs capabilities including:

  • Language Server Protocol (LSP) integration through xref commands for intelligent code navigation (eglot, lsp-mode and others)
  • Tree-sitter for syntax tree analysis and understanding code structure at the AST level
  • Imenu for structured symbol listing and navigation within files
  • Project integration for project-aware operations
  • Any Emacs command or function can be exposed as an MCP tool, allowing Claude to:
    • Perform project-wide searches and refactoring
    • Access specialized modes and their features
    • Execute custom Elisp functions tailored to your workflow

This deep integration means Claude Code understands your project context and can leverage Emacs’ extensive ecosystem to provide more intelligent and context-aware assistance.

Claude Code automatically knows which file you’re currently viewing in Emacs

Claude Code can access and work with selected text in your buffers

Integrated ediff view for code changes, with Claude Code able to directly access diagnostic data (errors, warnings, etc.) from opened files

Automatically mention and reference selected text in Claude conversations

Resume previous Claude Code conversations with the –resume flag

  • Emacs 28.1 or higher
  • Claude Code CLI installed and available in PATH
  • vterm or eat package (for terminal support)

Follow the installation instructions at Claude Code Documentation.

Currently, this package is in early development. To install using use-package and straight.el:

(use-package claude-code-ide :straight (:type git :host github :repo "manzaltu/claude-code-ide.el") :bind ("C-c C-'" . claude-code-ide-menu) ; Set your favorite keybinding :config (claude-code-ide-emacs-tools-setup)) ; Optionally enable Emacs MCP tools

The easiest way to interact with Claude Code IDE is through the transient menu interface, which provides visual access to all available commands. Simply run M-x claude-code-ide-menu to open the interactive menu.

CommandDescription
M-x claude-code-ide-menuOpen transient menu with all Claude Code commands
M-x claude-code-ide-emacs-tools-setupSet up built-in MCP tools (e.g. xref, project)
M-x claude-code-ideStart Claude Code for the current project
M-x claude-code-ide-send-promptSend prompt to Claude from minibuffer input
M-x claude-code-ide-continueContinue most recent conversation in directory
M-x claude-code-ide-resumeResume Claude Code with previous conversation
M-x claude-code-ide-stopStop Claude Code for the current project
M-x claude-code-ide-switch-to-bufferSwitch to project’s Claude buffer
M-x claude-code-ide-list-sessionsList all active Claude Code sessions and switch
M-x claude-code-ide-check-statusCheck if Claude Code CLI is installed and working
M-x claude-code-ide-insert-at-mentionedSend selected text to Claude prompt
M-x claude-code-ide-send-escapeSend escape key to Claude terminal
M-x claude-code-ide-insert-newlineInsert newline in Claude prompt (sends \ + Enter)
M-x claude-code-ide-toggleToggle visibility of Claude Code window
M-x claude-code-ide-show-debugShow the debug buffer with WebSocket messages
M-x claude-code-ide-clear-debugClear the debug buffer

Claude Code IDE automatically detects your project using Emacs’ built-in project.el. Each project gets its own Claude Code instance with a unique buffer name like *claude-code[project-name]*.

You can run multiple Claude Code instances simultaneously for different projects. Use claude-code-ide-list-sessions to see all active sessions and switch between them.

  • Running claude-code-ide when a session is already active will toggle the window visibility
  • The window can be closed with standard Emacs window commands (C-x 0) without stopping Claude
VariableDescriptionDefault
claude-code-ide-cli-pathPath to Claude Code CLI"claude"
claude-code-ide-buffer-name-functionFunction for buffer namingclaude-code-ide--default-buffer-name
claude-code-ide-cli-debugEnable CLI debug mode (-d flag)nil
claude-code-ide-cli-extra-flagsAdditional CLI flags (e.g. “–model”)""
claude-code-ide-debugEnable debug loggingnil
claude-code-ide-terminal-backendTerminal backend (vterm or eat)'vterm
claude-code-ide-log-with-contextInclude session context in log messagest
claude-code-ide-debug-bufferBuffer name for debug output"*claude-code-ide-debug*"
claude-code-ide-use-side-windowUse side window vs regular buffert
claude-code-ide-window-sideSide for Claude window'right
claude-code-ide-window-widthWidth for side windows (left/right)90
claude-code-ide-window-heightHeight for side windows (top/bottom)20
claude-code-ide-focus-on-openFocus Claude window when openedt
claude-code-ide-focus-claude-after-ediffFocus Claude window after opening edifft
claude-code-ide-show-claude-window-in-ediffShow Claude window during edifft
claude-code-ide-system-promptCustom system prompt to appendnil
claude-code-ide-enable-mcp-serverEnable MCP tools servernil
claude-code-ide-mcp-server-portPort for MCP tools servernil (auto-select)
claude-code-ide-mcp-server-toolsAlist of exposed Emacs functionsnil
claude-code-ide-diagnostics-backendDiagnostics backend (auto/flycheck/flymake)'auto
claude-code-ide-prevent-reflow-glitchPrevent terminal reflow glitch (bug #1422)t

Claude Code buffers open in a side window by default. You can customize the placement:

;; Open Claude on the left side
(setq claude-code-ide-window-side 'left) ;; Open Claude at the bottom with custom height
(setq claude-code-ide-window-side 'bottom claude-code-ide-window-height 30) ;; Open Claude on the right with custom width
(setq claude-code-ide-window-side 'right claude-code-ide-window-width 100) ;; Don't automatically focus the Claude window
(setq claude-code-ide-focus-on-open nil) ;; Keep focus on ediff control window when opening diffs
(setq claude-code-ide-focus-claude-after-ediff nil) ;; Hide Claude window during ediff for more screen space
(setq claude-code-ide-show-claude-window-in-ediff nil)

Or, if you’d prefer to use a regular window:

;; Use regular window instead of side window
(setq claude-code-ide-use-side-window nil)

Claude Code IDE supports both vterm and eat as terminal backends. By default, it uses vterm, but you can switch to eat if preferred:

;; Use eat instead of vterm
(setq claude-code-ide-terminal-backend 'eat) ;; Or switch back to vterm (default)
(setq claude-code-ide-terminal-backend 'vterm)

The eat backend is a pure Elisp terminal emulator that may work better in some environments where vterm compilation is problematic. Both backends provide full terminal functionality including color support and special key handling.

Claude Code IDE adds custom keybindings to the terminal for easier interaction:

KeybindingCommandDescription
M-RETclaude-code-ide-insert-newlineInsert a newline in the prompt
C-<escape>claude-code-ide-send-escapeSend escape key to cancel operations

These keybindings are automatically set up for both vterm and eat backends and only apply within Claude Code terminal buffers.

Claude Code IDE includes a temporary workaround for a known Claude Code bug (#1422) where terminal reflows during window resizes can cause uncontrollable scrolling. This workaround is enabled by default but can be disabled if needed:

;; Disable the terminal reflow glitch prevention (not recommended until bug is fixed)
(setq claude-code-ide-prevent-reflow-glitch nil)

The workaround will be removed once the upstream bug is fixed.

Claude Code IDE supports both Flycheck and Flymake for code diagnostics. By default, it will automatically detect which one is active:

;; Let Claude Code automatically detect the active diagnostics backend
(setq claude-code-ide-diagnostics-backend 'auto) ; default ;; Or force a specific backend
(setq claude-code-ide-diagnostics-backend 'flycheck)
(setq claude-code-ide-diagnostics-backend 'flymake)

You can customize how Claude Code buffers are named:

(setq claude-code-ide-buffer-name-function (lambda (directory) (if directory (format "*Claude:%s*" (file-name-nondirectory (directory-file-name directory))) "*Claude:Global*")))

You can pass additional flags to the Claude Code CLI:

;; Use a specific model
(setq claude-code-ide-cli-extra-flags "--model opus") ;; Pass multiple flags
(setq claude-code-ide-cli-extra-flags "--model opus --no-cache") ;; Flags are added to all Claude Code sessions

Note: These flags are appended to the Claude command after any built-in flags like -d (debug) or -r (resume).

You can append a custom system prompt to Claude’s default prompt, allowing you to customize Claude’s behavior for specific projects or contexts:

;; Set a custom system prompt
(setq claude-code-ide-system-prompt "You are an expert in Elisp and Emacs development.") ;; Or configure it per-project using dir-locals.el
;; In .dir-locals.el:
((nil . ((claude-code-ide-system-prompt . "Focus on functional programming patterns and avoid mutations.")))) ;; Set via the transient menu: M-x claude-code-ide-menu → Configuration → Set system prompt

When set, this adds the --append-system-prompt flag to the Claude command. Set to nil to disable (default).

To enable debug mode for Claude Code CLI (passes the -d flag):

(setq claude-code-ide-cli-debug t)

To enable debug logging within Emacs (logs WebSocket messages and JSON-RPC communication):

(setq claude-code-ide-debug t)

Then view debug logs with:

  • M-x claude-code-ide-show-debug - Show the debug buffer
  • M-x claude-code-ide-clear-debug - Clear the debug buffer

The debug buffer shows:

  • WebSocket connection events
  • All JSON-RPC messages (requests/responses)
  • Error messages and diagnostics
  • General debug information with session context

Using git worktrees is the recommended way for running multiple Claude Code instances on different branches of the same project. This allows you to develop features or fix bugs in parallel:

# Create a new worktree for a feature branch
git worktree add ../myproject-worktree feature-branch
;; Start Claude Code in the main project
find-file /path/to/myproject
M-x claude-code-ide ;; Start another Claude Code instance in the worktree
find-file /path/to/myproject-worktree
M-x claude-code-ide

Each worktree is treated as a separate project by project.el, allowing you to have independent Claude Code sessions with their own buffers (e.g., *claude-code[myproject]* and *claude-code[myproject-worktree]*).

Claude Code IDE includes built-in MCP tools that expose Emacs functionality to Claude, enabling powerful code navigation and analysis capabilities:

  • xref-find-references - Find all references to a symbol throughout the project
  • xref-find-apropos - Find symbols matching a pattern across the entire project
  • treesit-info - Get tree-sitter syntax tree information for deep code structure analysis
  • imenu-list-symbols - List all symbols (functions, classes, variables) in a file using imenu
  • project-info - Get information about the current project (directory, files, etc.)

To enable these tools, add to your configuration:

;; Set up the built-in Emacs tools
(claude-code-ide-emacs-tools-setup)

Once enabled, Claude can use these tools to navigate your codebase. For example:

  • “Find the definition of function foo”
  • “Show me all places where this variable is used”
  • “What type of AST node is under the cursor?”
  • “Analyze the parse tree of this entire file”
  • “List all functions and variables in this file”
  • “How many files are in this project?”

You can expose your own Emacs functions to Claude through the MCP tools system. This allows Claude to interact with specialized Emacs features, custom commands, or domain-specific functionality.

Each tool definition in claude-code-ide-mcp-server-tools follows this format:

'(function-name :description "Human-readable description for Claude" :parameters ((:name "param1" :type "string" :required t :description "What this parameter does") (:name "param2" :type "number" :required nil :description "Optional parameter")))
(defun my-project-grep (pattern) "Search for PATTERN in the current session's project." (claude-code-ide-mcp-server-with-session-context nil ;; This executes with the session's project directory as default-directory (let* ((project-dir default-directory) (results (shell-command-to-string (format "rg -n '%s' %s" pattern project-dir)))) results))) (add-to-list 'claude-code-ide-mcp-server-tools '(my-project-grep :description "Search for pattern in project files" :parameters ((:name "pattern" :type "string" :required t :description "Pattern to search for"))))

This project is licensed under the GNU General Public License v3.0 or later. See the LICENSE file for details.


Read the original article

kgwgk

Karma: 16337
...
 @Hacker__News
@hacker._news

Comments

  • By blahgeek 2025-08-0614:017 reply

    Like LSP and tree-sitter, I think AI coding tools like Claude Code or Aider are very good news for niche editors like Emacs or Vim. Instead of struggling about implementing advanced IDE-like features, they can integrate with these tools relatively easily, and focus on other editing related features that set them apart. In fact, IMO it makes these editors more competitive because they are highly customizable and easier to integrate with these tools.

    • By throwaway4496 2025-08-072:3910 reply

      You think VIM is a niche? neovim + vim is used by over 38% of developers according StackExchange survey. That is more than 1 out of 3 developer, closer to 2 out of 5.

      I am not sure what is going on with here recently, maybe I have overgrown the place, or maybe everyday a little by little this place is getting filled with people who shouldn't be talking about CS.

      • By blahgeek 2025-08-074:423 reply

        As someone who have only used Emacs and Vim in the past 10 years, I wish you are right. But according to my observation, 90% of those 38% of developers only use Vim in when they are sshing to the server to update few config files or make simple edits to the scripts. When they do proper programming (like hundreds lines of coding in a project), they switch to other IDEs like VSCode. So yes I personally still consider Vim and Emacs “niche” editors.

        • By throwaway4496 2025-08-075:522 reply

          Yeah, even if that is true, what part of a tool used by close to 40% of developers is niche?

          niche /niːʃ,nɪtʃ/ (adjective) denoting products, services, or interests that appeal to a small, specialized section of the population.

          • By davrosthedalek 2025-08-078:141 reply

            It's niche /for development work/. Being used by a developer doesn't make it used for development. Or the most used developing tool would be the toilet.

            • By throwaway4496 2025-08-078:442 reply

              [flagged]

              • By AndyPa32 2025-08-078:572 reply

                It's not. I use vim on a daily basis, but all I do with it is writing commit messages. The rest I do with an IDE or different editor. I'm surely not alone with that.

                • By johnisgood 2025-08-079:30

                  Even I switch to VSCodium when I write Go, for example, because the Go extension is just so good. I use it for medium- and large-sized projects, when I have to navigate through multiple files. There are ways to do it in Vim (I configured it), and Emacs, but sometimes it really is just easier to click since I am already using the mouse for stuff. There are people who never use their mouse, in which case I can imagine they use Emacs or Vim only.

                • By throwaway4496 2025-08-079:321 reply

                  And writing commit messages are to development in the same class as using the restroom?

                  • By moi2388 2025-08-0717:58

                    Judging by the quality of most commit messages - yes.

              • By BeetleB 2025-08-0715:18

                > Yeah, because I use vim to turn on the shower.

                You say that as if it's ridiculous. Isn't there an M-x shower-on command somewhere in Emacs?

          • By epcoa 2025-08-0713:11

            While not going to argue that vim is niche, I don’t think it is. StackExchange surveys are likely highly unrepresentative and lack external validity. I do not believe 40% of developers use vim based on such an unvalidated and likely biased study.

        • By worthless-trash 2025-08-078:34

          In rhr group if hundred plus programmers I work with, id estimate less than 5 percent use anything but emacs and vim.

          The other tooling feels niche to me.

        • By nojs 2025-08-075:24

          Worth noting that a lot of people use those IDEs with vim keys

      • By xmhsez 2025-08-075:342 reply

        I've been using vim for 10+ years. The only commands I know are for saving, quitting, enabling line numbers and syntax. I'm sure 90% of the people in your statistics are like me.

        • By simtel20 2025-08-0720:36

          I have met people who said they use vim for programming and don't know how to use commands like `%s` and `G` to do those basic things. I don't think most people understand how to use vim, and for those cases it's about the same as using any other editor with a find, and arrow keys and delete. That is, about as much an editor as any textarea in a browser.

        • By setopt 2025-08-0712:31

          If you create a vimrc, even an empty one, I believe you don’t have to enable syntax highlighting manually.

          (The existence of a Vim config file disables Vi compatibility mode.)

      • By siva7 2025-08-075:224 reply

        I believe rather my own eyes over a long career than these surveys. It's certainly well below 10% if you don't count being just used for the lack of any alternative (aka sshing)

        • By Arisaka1 2025-08-077:261 reply

          Placing greater weight in our own anecdotes over randomized trials and researches is what gave us some of the worst experiences in recent years.

          • By epcoa 2025-08-0713:23

            StackExchange surveys are not “randomized trials” and only qualifies as the lowest quality research.

        • By petepete 2025-08-077:27

          The group of devs makes all the difference.

          In my current role (contracting at a gov dept in a part that uses Rails and PostgreSQL) it's about 30% using vim or neovim.

          In the rest of the department where it's .net and Microsoft all the way, the devs likely have never heard of vim.

        • By throwaway4496 2025-08-075:42

          Based on my eyes, viruses do not exist. I can't see them anywhere. A sample size of "what I see" is not the best foundation for any claims.

        • By noosphr 2025-08-0710:40

          If only more people knew about tramp-mode.

      • By never_inline 2025-08-0717:483 reply

        > people who shouldn't be talking about CS.

        Dijkstra said computer science is about computers as much as astronomy is about telescopes.

        I am not sure I agree with that, but it's definitely not about text editor choice.

        I have a .vimrc file with LSPs and whatnot. But it was from 3 years back. These days I use VSCode and IntelliJ (depending on language) because they do so many things out of the box. I would say the choice of editor is the least consequential thing in one's understanding of "CS" and programming methodologies. On the other hand, using debuggers, profilers, monitoring tooling can have a real impact on how you solve some problems.

        • By wraptile 2025-08-085:061 reply

          > I am not sure I agree with that, but it's definitely not about text editor choice.

          It's definitely possible but I genuinely don't understand how people work for decades and still move their hand all the way to the arrow keys just go move the cursor to another word. Especially when the solution for this inefficiency is so accessible, existed for decades and is widely available in almost every tool. It's something that goes against the spirit of the medium which is all about automation.

          • By jama211 2025-08-0819:311 reply

            It’s not the bottleneck of true productivity. It doesn’t matter any more than how close the pedals are together would affect how long it takes me to drive somewhere.

            • By wraptile 2025-08-129:00

              I disagree, the older I get the more aware I am of how impactful even minor friction is. Having "pedals closer together" does in fact make you press the pedals more often especially when you do that thousands of times per day.

        • By ascagnel_ 2025-08-0718:39

          > These days I use VSCode and IntelliJ (depending on language) because they do so many things out of the box.

          While I don't appreciate the weight of an IDE, the time commitment to create (and maintain!) a config for vim/nvim with LSP, agents, etc., loses out to the relative ease of adding vim-style modal editing to the IDE.

        • By coldtea 2025-08-0810:28

          >Dijkstra said computer science is about computers as much as astronomy is about telescopes.

          He said many stupid things when it was outside of his domain of mathematics and algorithms.

      • By sunng 2025-08-073:161 reply

        According to StackExchange, Emacs is not even a code editor

      • By qwertywert_ 2025-08-0716:16

        Most "regular" developers don't actively engage with StackExchange.. I would not believe that statistic at all. And I'm a 7+ years vim user.

      • By elAhmo 2025-08-079:01

        Of course it is niche, that survey is quite skewed, and "using" doesn't mean doing development work there, rather than occasionally having to use it when using remote terminals.

        I know only one person from my dozens of developer friends and colleagues who is using neovim.

      • By LoFiSamurai 2025-08-079:411 reply

        > with people who shouldn't be talking about CS

        Your argument is that calling Vim niche should exclude someone from being able to talk about CS. Please rethink your stance and your tone and consider if you’re helping the discussion.

        • By 3836293648 2025-08-0917:14

          This is a much more hostile and unproductive comment than the one you're replying to

      • By wraptile 2025-08-084:58

        Not only that but many new editors straigh up ship vim mode now like Zed, Obsidian etc. The main vscode neovim plugin¹ is very big too with over 500k unique installs. Clearly VIM is still widely popular and not going away anytime soon.

        1 - https://github.com/vscode-neovim/vscode-neovim

      • By OtherwiseBenign 2025-08-074:44

        Well, in a survey, I‘d say that I’m using it - but mainly for quick configuration file edits on servers where nothing else is installed.

    • By dismalaf 2025-08-0615:15

      It's always been that way. Emacs has had advanced IDE-like features for as long as I can remember. Vim too.

      LSP and TS just make it easier to standardize across editors and languages.

    • By mikece 2025-08-0614:066 reply

      Is there a standard for integrating agentic coding tools into an editor similar to how an LSP allows the integration of language-specific features?

      • By benreesman 2025-08-0614:333 reply

        Its not at anything like the adoption of MCP or especially LSP, and it takes a more "foundational and composable library of primitives" approach than "wire protocol per se" approach, but `gptel` has quite the vibrant little ecosystem around it and its just god mode, wall hacks on the VSCode stuff, just blows it away. I'm under extreme time pressure at the moment, I cannot afford to fuck around on ideology right now I have to go for the jugular every day, and that means "fuck the cost" Opus 4 use in `gptel` (though Qwen and K2 are pushing it out of more and more stuff as I learn the quirks, Opus 4 TTFT under load is unusable and when it starts fighting you on clean merge boundaries because its personality vector has been set to "token stingy" its strictly worse).

        Its not that I dislike Cursor, its that I dont have time to put up with its compromises for non-extreme-power-user accessibility. I need an extreme power, cost indifferent, tuned for the margins stack.

        That's nothing with a VSCode base that I know about, and I've tried Cline and Roo and Continue and written a bunch MCP servers and I measure it all, not even close.

        I bet the neovim people have something just as good.

        • By sexyman48 2025-08-0616:143 reply

          cannot afford to fuck around, go for the jugular every day

          Slow your roll. Nothing you write will matter in six months.

          • By benreesman 2025-08-0617:411 reply

            Can't speak for you friend, but I got my ass kicked through a combination of the hiring freezes and absorbing a bunch of famiku-wide expenses around a nasty bereavement like, right before that and got pretty much wiped out. Having been very well off (to put it mildly) from like, 2010-2023, I was pretty unclear on the fact that going broke is straight up existential now in a way that was not true ten or fifteen years ago. If you've been doing alright for a decade or so, I wouldn't blame you for not knowing that.

            But as a guy who is a known enemy of the Valley establishment to begin with rebuilding from all that? When I say I'm dead serious, I'm being earnest.

            If you don't have a family/community safety net and/or a plugged-in nepo golden age network?

            Stack cash on hand like your life depends on it, because it fucking does.

            • By dingnuts 2025-08-0618:322 reply

              being broke was absolutely existential fifteen years ago.

              signed:

              someone who was broke fifteen years ago and has been stacking cash on hand ever since.

              • By benreesman 2025-08-0618:51

                I believe you, my situation might have been different. I never had much growing up and never had good jobs until like my mid 20s, I remember it sucking to be broke but not being scary if that makes sense? You could usually find at least a shitty job and even a shitty job could get you some kind of apartment or room even with bad credit. Nice apartments had hard credit checks but there were independent landlords everywhere, so if you didn't mind the occasional drug deal on your block, it was like, workable. Now its all property management companies with what amounts to one computer system and if you don't like it? AirBnB is happy to absorb every last house, room, carboard box, and park bench.

                And a shitty job is no guarantee of a shitty room now, you see homeless people still in the Best Buy shirt they were wearing when they got laid off, and Best Buy is nowhere near the worst job.

                I thought working hard and being really good at computer stuff was basically some kind of bare minimum job guaranteed, that being free with my money might mean not retiring young. Didn't realize tech employment was war.

                Wrong. Won't make that mistake again.

              • By aaronbaugher 2025-08-0620:09

                Ditto. Being broke has always been existential, and pretty damn scary even if you had family and other resources you could lean on. Nothing's changed about that, though particular industries/regions may get better or worse.

          • By kabdib 2025-08-0616:42

            the code that i am least proud of is the code that has lasted the longest :-)

          • By szundi 2025-08-0616:34

            [dead]

        • By ljm 2025-08-0615:22

          My 'beef' with Cursor is that the editor is part of the package and you don't really have the same kind of hooks into the agent that you do with Claude Code or similar, which really means you're at the mercy of the Cursor team to prioritise those things on their roadmap. That includes things like the limit of 40 MCP tools that you can only enable globally (and MCP proxies that try to do this dynamically are a bit flakey) - even just using the GitHub MCP blows through that limit because it's all or nothing.

          It's good for what it is but I don't love that I have to change to a whole-ass new editor to get access to the agentic additions, when alternatives that require an API key or a more flexible CLI tool can do a better job.

        • By cvdub 2025-08-0615:391 reply

          Are you using gptel exclusively, or also things like aider/claude code?

          I’d love to hear more about your workflow if you have time to share!

          • By benreesman 2025-08-0615:524 reply

            Sure. I'm experimenting like everyone else, but I mostly use gptel as the primary interaction surface and Claude Code for a range of refactorings and other "more than mechanical, less than creative" edits. Both of these are very (!!!) well complimented by magit, which is so good at AI supervision it seems designed for it, by a genius.

            For Claude Code I'm rapidly switching anything I want "vibe coded" into Hadkell for code, Dhall for config, and check-heavy Nix for deploy. Between that and some property tests that I seed and then have Opus elaborate on, you can put Claude Code so restrictive that it just hits the compiler in a loop until useful code comes out. Its trapped: I hoist CLAUDE.md in from the Nix store so it physically can't edit out the brutal prompts around mocks and lies, and -Wall -Werror in GHC gives it nowhere to hide, all it can do is burn tokens and desperately Web Search tool until it gets it perfect ish or I cut off its money because this requires a real LLM minimum and likely a real programmer. If there's a property test welded into the type system it can't even fail to use a parameter: that's an error Claude.

            I have a bunch of elisp in // hypermodern // emacs for things like OpenRouter integration and tool use, but frankly, stock gptel is so strong I always wonder if I'm getting my money's worth trying to tune it into the asymptote.

            Happy to answer any more questions.

            • By aquariusDue 2025-08-0616:331 reply

              Sounds wild! What have you built this way?

              Also as another Emacs user I'm wondering what lesser known packages or elisp snippets do you use? gptel, magit, tramp and org-mode are the usually touted killer features, but what else do you use in the Emacs ecosystem?

            • By yablak 2025-08-0620:551 reply

              Share your dotemacs/gptel config? I'm not in love with emacs eider integration. Wondering how to put direct editing/control to the model. Still very cludgy with gptel though I've been using it for months

            • By AlexCoventry 2025-08-0620:131 reply

              Sounds cool. What sort of stuff do you develop, and who's paying for it?

              • By benreesman 2025-08-0622:121 reply

                I work for a medium-sized proprietary/discretionary fund. AFAIK the principles trade all kinds of stuff, macro stuff. My current job is tuning up the execution on the cryptocurrency adjacent desk, but not like blockchain stuff, it's somewhere in between OG crypto trading stuff and like Wall St. HFT circa 2006-2010 depending on how you measure, it's in the "kernel bypass matters but FPGAs are still exotic" sort of regime, some of it is legacy REST APIs still but FIX 4.2 SBE and other real finance protocols (and real banks and stuff) are starting to be a part of the ecosystem.

                I aspire to be a lot faster than this stuff (I've built faster stuff than this) but this is quite a good library (amazingly good by OSS standards, good stuff in this area is rarely OSS, props to the maintainers): https://github.com/crypto-chassis/ccapi, in particular this library does a really good job of being correct across a lot of surface area, it's serious people doing it, and there are forks of it that use DPDK floating around.

                If by who's paying for it you mean the big Anthropic bill? My boss's boss is pretty enlightened about the fact that learning how to use AI well is expensive, so when I'm on a tight schedule I get a pretty forgiving budget for the model fees. It's a pretty serious perk in the sense that it's really expensive to master using these things :)

            • By neutronicus 2025-08-0620:241 reply

              I have a couple more!

              I take it this is all back-end work? Have you tried out one of the Haskell-y front-end languages? Elm?

              > Both of these are very (!!!) well complimented by magit, which is so good at AI supervision it seems designed for it, by a genius.

              Can you expand a little on this point?

              • By benreesman 2025-08-0622:141 reply

                I very much recommend just watching some of the great `magit` videos on youtube, but later on when I have time I'll do a little `asciinema` of like, a Claude Code interaction and reviewing / piecewise incorporating the bots changes, so if you check back here tonight or tomorrow latest I'll do a little demo.

                • By louistsi 2025-08-116:43

                  Did you get the chance to record this? I'd quite like to see it.

      • By lukaszkorecki 2025-08-0616:44

      • By godelski 2025-08-0622:24

        I'm sure some other users can give you better answers, but I'm a bit curious what you mean by "standard".

        FWIW, Vim (and presumably emacs) can run terminals as well as do things like ssh and ftp. Though I'm pretty sure the easiest thing to do would just be to use the Ctrl-R pattern in vim and have it send curl requests in a different buffer. As far as I'm aware, all the major LLM platforms have APIs that can be accessed through curl (or any other way you want to to GET/PUT requests). Here's something I found with a quick Google search[0].

        So I'm not sure there needs to be "a standard" so much as "can it do http requests?" which is yes. I mean with this I think you can also see it wouldn't be too hard to set up and connect to a LLM hosted on the LAN. Could do it all through ssh

        [0] https://arjunaravind.in/blog/using-vim-as-a-http-client/

      • By newtwilly 2025-08-070:48

        No the comment meant that aider and Claude code are CLI programs, so if you can run a terminal in your niche editor, then you are good to go

      • By didibus 2025-08-0617:42

        There's this one: https://eca.dev/

      • By __MatrixMan__ 2025-08-0616:27

        There's a fair bit of discussion about this here: https://github.com/helix-editor/helix/discussions/4037

        But the short answer is no. Not yet.

        I'm pretty happy just letting the standalone agent write to the file and then reloading it in my editor.

        Though I wish the agent CLI tools would use something like inotify to notice when I've made a manual change to a file that they've recently written and then do a better job of incorporating that change as feedback to inform future edits.

    • By peterjliu 2025-08-070:121 reply

      emacs and vim are not niche, lol

      • By mickael-kerjean 2025-08-071:442 reply

        In 15 years of using nothing but emacs, I have never met another emacs user in any of the companies I worked for. plenty of vim but literally 0 emacs

        • By iLemming 2025-08-073:34

          I have a similar but opposite experience. Since around 2015 I've mostly been working with people who primarily use Emacs. In 2014 I was the only weird one, then next team about 3-5, then a dozen, then there was a team of a few dozen where only two were using Vim. On my current team also most of the devs are Emacs users. However, a lot of people use Emacs with Evil-mode, so I guess they can be considered vimmers.

          Also, I don't remember the last time when I worked with anyone who writes code and uses Windows.

          Anecdotal experiences can lead to a warped understanding of reality; in mine, Windows and non-emacs users are niche.

        • By reddit_clone 2025-08-074:021 reply

          My experience aligns with this. I work for a bigco. Yet to meet a fellow Emacs user.

          • By kelvie 2025-08-075:231 reply

            Don't y'all have a #emacs slack channel or equivalent at your company? I work for a medium-sized tech company and we have a single digit amount of emacs users I feel like. The channel is mostly dead except for a few tips and tricks and the odd time people asking how we each install it on our macbooks.

            Anecdotally a lot of managers use Emacs, though that may be an age thing.

            (I use emacs for Real Work, unless that Real Work involves a JVM. Still do all the git stuff in emacs/magit, though)

            • By reddit_clone 2025-08-090:26

              Yep. I do as much real work as possible in Emacs. Magit/Org-Mode/Org-roam/Org-gtd/Babel are all pretty essential to my workflow.

    • By bunjeejmpr 2025-08-0617:232 reply

      [flagged]

      • By chamomeal 2025-08-0618:43

        I don’t see a lot of rage bait on HN. Is this bait or just super weird?

      • By wizhi 2025-08-0617:281 reply

        Man, if anything you sound like a pretty shit coworker.

    • By deadbabe 2025-08-0620:12

      [flagged]

  • By yoyohello13 2025-08-0615:423 reply

    I’ve always thought emacs is the ultimate editor for AI agents. The agent has so much access to the state of the editor itself and can even easily change editor behavior with elisp. I feel like editors which expose the level of customization like vim and emacs could potentially have a huge advantage.

    • By iLemming 2025-08-0618:411 reply

      > vim and emacs could potentially have a huge advantage.

      They always have had. It just depends on what people perceive to be advantageous. For me, VSCode's and IntelliJ's closed model for extensibility is a huge downside.

      By "closed" I mean - restrictive plugin APIs, sandboxed execution environment, corporate gatekeeping, opaque core, etc.

      I don't even try to "shop for more features" anymore, learning Emacs allows me to remain "goal-oriented", and more often than not, it enables me to get the shit done in a far more satisfactory manner. Meanwhile, almost every time I switch to IDEs, I hit some limitations. It's not even "skill-issue" or unfamiliarity, I do remember my days of using IntelliJ, of which I was a devoted user for almost a decade. The way how I solve problems with Emacs, is just not even close.

      • By smaudet 2025-08-0619:291 reply

        I went (10 years ago) JetBrains because of emacs. Back then, they were the Kool Kid in town that made emacs-style functionality more accessible.

        More and more they've become just another IDE with too-much-to-do. Still one of (the?) best, but as soon as your editor becomes impractical to use to edit a text file... (because it really just likes to work on projects...).

        But yeah, emacs remains functional in a way that JetBrains...probably won't. I'm already more than several years behind on their releases because they stopped putting a decent product...

        • By iLemming 2025-08-0622:06

          Oh boy, I was such a jetbrains kiddo, I can't even tell you. I had posters on my wall with keybinding and commands cheat sheets, I knew people working for JetBrains by their names, I talked to them regularly, it almost felt like we were on the same team. I tried to debug and understand plugins, even wanted to develop one, but somehow never got to do that - the hacking mindset of a habitual programmer just wasn't there yet - I kinda went with the status quo - "if IntelliJ doesn't have this feature, maybe I don't even need to know about it..." I've discovered and reported so many bugs on YouTrack, I still receive updates on them, even today - some of them date to 2009, things that JetBrains never even tried to improve since then.

          WebStorm was probably the biggest reason why it took me so long to switch to Emacs. My biggest fear was that if I invested in learning Emacs, and at some point I'd inevitably find that something simply couldn't be done in it, and I'd be forced to go back and my idyllic life would be ruined. God, how wrong I was. Not only have I found _everything_ I needed, I actually discovered radically different ways of solving problems.

          In the end, turns out one thing jetbrains did right - they have nailed the marketing - I surrendered without resistance. My biggest regret is not trying out Emacs sooner. I wish someone very persuasive showed me things I did not know were possible. That's why I get very vocal about it - kids have zero idea what they'd be missing.

    • By ethan_smith 2025-08-0622:29

      Emacs' advantage comes from its Lisp interpreter core - AI agents can introspect and modify the entire editor state at runtime through the same evaluation mechanisms that users employ, unlike most editors with rigid plugin APIs.

    • By finaard 2025-08-075:22

      This is true - and a reason I'm not sure about this package. I'll still try it, but I don't think it's the right way forward.

      Pretty much the only advantage is that you get access to logic available in the claude code CLI - which in large parts probably already exists in emacs or extensions. On the downside it'll bind you to claude code.

      I'm generally using a generic LLM wrapper - emacs has two good ones, gptel and llm. I have both configured, as both are required by some of the extensions I'm using, but currently prefer gptel: It seems to be more advanced, especially when it comes to tool use.

      Advantage of that approach is that when you're hitting a wall with one LLM being stupid with one specific issue you can just switch to a different one. Or you can use the same environment with locally hosted LLMs.

      Disadvantage is that the IDE/project functionality is not tied up that nicely yet - there are a few attempts (like minuet or evedel), but nothing I really got into.

      Currently I'm mostly doing a chat buffer, and the LLM has tools available to inspect and to some extend alter the current state, published here: https://github.com/aard-fi/gptel-tool-library - that works pretty well on a per file basis, and to some extend it can figure out project details, but overall it lacks project info - in part that's a context limitation thing, where that info should be provided as additional context for each instruction (which I assume the CLI is doing).

      What this approach also nicely enables is fun experimentations:

      - https://github.com/aard-fi/buffer-turtle implements simple turtle graphics in an emacs buffer, and has bindings for the LLM to control the turtle - https://github.com/aard-fi/arch-installer has the glue to have the LLM interact with a serial port, and some glue (like basic ANSI escape parsing) to make the result look somewhat reasonable in an emacs buffer. That allows it to do stuff like trying to install Arch linux in a VM

      Both repos have links to youtube videos with some runs.

  • By vemv 2025-08-0614:001 reply

    I'm happily using https://github.com/stevemolitor/claude-code.el which is a mere terminal wrapper (including a nifty Transient menu). But just by virtue of running inside Emacs you get a lot of power - it didn't take me a lot of effort to create an efficient, customized workflow that felt much more streamlined than my older iTerm usage.

    I'll keep an eye on this new offering though.

    There's also https://github.com/editor-code-assistant/eca-emacs which comes from the author of clojure-lsp, a very popular package within the Clojure community. I'd also been wanting to try it.

    For both of the more advanced offerings, I tend to be a little cautious when adopting tools I'm trusting my productivity to. Most ambitious projects need to iron out misc stuff during their 'big bang' phase.

    • By mijoharas 2025-08-0615:181 reply

      I tried that for a bit, and bounced back to just using claude code in a terminal. It was a little bit janky in emacs, and didn't have any features that justified not just running a separate terminal window (for me, at the time I checked it out).

      I'm wondering if this project will work. It does feel a shame that it doesn't work with the existing mcp.el package[0], but I never got around to setting that up anyways. I wonder if it's a limitation of the package? or not wanting another dependency?

      (in addition I've only really played around with claude code a little because I haven't gotten it to a place where I can make it write code I'd consider acceptable for my day job.)

      [0] https://github.com/lizqwerscott/mcp.el

      • By yogsototh 2025-08-0617:28

        I personally have great success with gptel + mcp + claude (via copilot due to corporate restrictions)

        I wrote a short article about how I configured it there: https://her.esy.fun/posts/0029-ai-assistants-in-doom-emacs-3...

        One thing I really appreciate with gptel is that it is very easy to switch from Claude to something else like a local llm (via ollama or gpt4all for example). And the interface will be similar.

HackerNews

About