Emacs के लिए Claude Code IDE एकीकरण

 (github.com/manzaltu)
1 पॉइंट द्वारा GN⁺ 2025-08-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Code IDE for Emacs Emacs के अंदर Claude Code CLI को native तरीके से एकीकृत करके एक मजबूत AI कोडिंग असिस्टेंट environment देता है
  • Model Context Protocol(MCP) आधारित दो-तरफा bridge के माध्यम से Claude Emacs के LSP, project management, Elisp functions आदि विभिन्न फीचर्स का उपयोग कर सकता है
  • ऑटोमेटिक प्रोजेक्ट डिटेक्शन, मल्टीपल सेशन, diagnostics (error/warning) इंटीग्रेशन, advanced diff, tab-bar और चयन/buffer ट्रैकिंग जैसी Emacs-ऑप्टिमाइज़्ड फीचर्स उपलब्ध कराता है
  • Emacs कमांड और extensibility के आधार पर, MCP server के जरिए सीधे commands expose करना और कस्टम वर्कफ्लो इंटीग्रेशन संभव है
  • Claude और पूरा Emacs ecosystem के बीच गहरा कनेक्शन बनाकर cloud-based AI-सहायक development environment तैयार करता है

अवलोकन

Claude Code IDE for Emacs, Claude Code CLI के साथ इंटीग्रेशन के ज़रिए Emacs के अंदर Claude AI की क्षमताओं को अधिकतम करने वाला एक ओपन सोर्स प्रोजेक्ट है। यह सिर्फ एक सरल टर्मिनल रैपर नहीं है; यह MCP(Model Context Protocol) आधारित दो-तरफ़ा communication bridge देता है, जिससे Claude Emacs की अंदरूनी सुविधाओं का वास्तविक उपयोग कर सकता है। यह LSP, project management, Elisp functions आदि के साथ Emacs के शक्तिशाली ecosystem से जुड़कर Emacs उपयोगकर्ताओं के लिए एक productiv​e और intelligent AI development support environment प्रदान करता है।

मुख्य विशेषताएँ

  • ऑटोमेटिक परियोजना पहचान और सेशन प्रबंधन

    • Emacs built-in project.el का उपयोग करके, परियोजनाओं की स्वतः पहचान और सेशन अलग करना
    • प्रत्येक प्रोजेक्ट के लिए अलग Claude Code instance और buffer उपलब्ध कराना

  • टर्मिनल इंटीग्रेशन और color सपोर्ट

    • vterm या eat के जरिए color terminal सपोर्ट
    • Emacs के अंदर ही Claude से बातचीत करना

  • MCP प्रोटोकॉल के माध्यम से IDE इंटीग्रेशन

    • विभिन्न Emacs commands (code navigation, symbol lookup, AST analysis आदि) को MCP server के जरिए expose करना
    • Claude को Emacs commands तथा user-defined functions execute करने की अनुमति

  • उच्च विस्तार योग्य MCP Tools server

    • कस्टम MCP tool जोड़ना/define करना संभव (उदाहरण: पूरे प्रोजेक्ट में खोज, global refactoring आदि)

  • कोड diagnostics और diff

    • Flycheck और Flymake इंटीग्रेशन के जरिए कोड error/warning diagnostics जानकारी
    • ediff के साथ advanced diff view और diagnostics तक पहुँच

  • स्टेट/command ट्रांज़िशन प्रबंधन

    • tab-bar, चयन/buffer ट्रैकिंग आदि से Claude उपयोगकर्ता का वर्तमान context समझ सकता है

Emacs Tool Integration

Claude Code IDE MCP tool सिस्टम के माध्यम से Emacs के अनेक command और जानकारी सीधे Claude को उपलब्ध कराता है

  • LSP इंटीग्रेशन(xref)

    • Go-to-definition, प्रोजेक्ट-व्यापी symbol/reference खोज आदि LSP-आधारित intelligent खोज का सपोर्ट

  • Tree-sitter सपोर्ट

    • syntax tree parsing और AST(एब्स्ट्रैक्ट सिंटैक्स ट्री) आधारित code structure की समझ

  • Imenu, Project इंटीग्रेशन

    • symbol सूची, प्रोजेक्ट फाइल और structure information की स्वचालित उपलब्धता

  • यूज़र-डिफ़ाइंड Elisp फंक्शन

    • MCP tool के रूप में सीधे expose करके, custom workflow/domain-specific फीचर्स का उपयोग

इस इंटीग्रेशन से Claude Emacs ecosystem की context जानकारी का उपयोग करके कोड-स्तर पर सटीक AI सहायता दे सकता है

उपयोग

बुनियादी कमांड

  • M-x claude-code-ide-menu: सभी कमांड को विज़ुअली दिखाने वाला transient menu खोलता है
  • प्रोजेक्ट के भीतर Claude Code ऐक्टिव करना, prompt भेजना, पिछली चैट जारी रखना और विभिन्न state/session प्रबंधन उपलब्ध कराना
  • कई प्रोजेक्ट को एक साथ manage किया जा सकता है, और प्रत्येक प्रोजेक्ट के लिए अलग Claude session चलाना संभव है

विंडो और सेशन प्रबंधन

  • यदि नया सेशन पहले से रन कर रहा हो तो केवल विंडो toggle/दिखाना होता है
  • Standard Emacs कमांड (C-x 0) से विंडो बंद होने पर भी Claude बंद नहीं होता

सेटिंग

  • Claude Code CLI, terminal backend, diagnostics backend, विंडो position/size, debug options आदि का granular customization support
  • अतिरिक्त flags जोड़ना, system prompt सेट करना, buffer नामकरण function जैसे advanced options उपलब्ध
  • MCP server को एक्टिवेट करने और इस्तेमाल होने वाले tools/ports सेट करने की सुविधा

Terminal Backend सेटिंग

  • डिफ़ॉल्ट रूप से vterm, जरूरत होने पर eat backend पर switch किया जा सकता है
  • eat एक pure Elisp-आधारित terminal है, अगर vterm build में issue आए तो उपयोगी
  • समर्पित keybindings उपलब्ध हैं (M-RET: prompt में लाइन-ब्रेक, C-<escape>: exit/cancel आदि)

डायग्नोस्टिक्स/डिबग विकल्प

  • Flycheck, Flymake को auto-detect/integrate या force चयन करने की सुविधा
  • Claude terminal reflow (re-layout) बग (#1422) से बचाव के लिए temporary workaround option मौजूद
  • Emacs और CLI दोनों स्तरों पर detailed debugging logs का सपोर्ट (WebSocket, JSON-RPC messages आदि की जाँच)

Advanced: कई Worktree, सेशन ऑपरेशन

  • git worktree का इस्तेमाल करके, एक ही प्रोजेक्ट में अलग branches पर कई independent सेशन चल सकते हैं
  • प्रत्येक वर्कग्रुप के लिए अलग buffer और context बनाए रखकर parallel development वर्कफ्लो को सपोर्ट करता है

Emacs MCP Tools विवरण

इन-बिल्ट MCP Tools उदाहरण

  • xref-find-references: प्रोजेक्ट के अंदर किसी specific symbol के सभी reference खोजता है
  • xref-find-apropos: pattern-आधारित symbol/code पूर्ण खोज
  • treesit-info: tree-sitter आधारित AST analysis डेटा उपलब्ध कराता है
  • imenu-list-symbols: फाइल के अंदर सभी functions और variables की सूची दिखाता है
  • project-info: वर्तमान प्रोजेक्ट की metadata और फाइल जानकारी देता है

यूज़र-डिफ़ाइंड टूल जोड़ना

  • यूज़र अपने Emacs functions को MCP tool format के अनुसार जोड़ सकता है
  • उदाहरण के तौर पर, ripgrep पर आधारित code search टool या किसी domain-specific command को define करके सीधे Claude से कॉल किया जा सकता है

लाइसेंस और संबंधित प्रोजेक्ट

  • GNU GPL v3.0 या उसके बाद के संस्करणों के साथ उपलब्ध
  • संबंधित प्रोजेक्ट्स में VS Code, Neovim(claudecode.nvim) इंटीग्रेशन plugins आदि शामिल हैं

महत्व और फायदे

Claude Code IDE for Emacs, परंपरागत LLM/AI integration tools से अलग, Emacs के अंदर मौजूद unique कार्य संदर्भ और ecosystem जानकारी का सक्रिय उपयोग करके एक मजबूत AI IDE environment प्रदान करता है।
हालाँकि यह अभी शुरुआती चरण में है, फिर भी इसमें विभिन्न built-in फीचर्स, उच्च स्तर की customization और multi-project support मौजूद है, जिससे Emacs उपयोगकर्ताओं और ओपन सोर्स डेवलपरों के लिए यह एक बेहद मजबूत विकल्प बनता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-07
Hacker News टिप्पणी
  • LSP और tree-sitter की तरह ही Claude Code या Aider जैसे AI coding tools का आना Emacs या Vim जैसी editor दुनिया के लिए सच में बड़ी अच्छी खबर है; अब पहले की तरह advance IDE फीचर्स खुद से implement करने के लिए अलग से जूझना नहीं पड़ता और इन tools से आसान integration करके अपनी editor-specific differentiation पर focus कर सकते हैं। सच में, यही customization और flexible integration इन editors की प्रतियोगी ताकत को बहुत बढ़ा देते हैं।
    • क्या LSP की तरह agent-style coding tools को editor में आसानी से integrate करने के लिए कोई standard मौजूद है?
    • मेरा हमेशा का यह मत रहा है कि Emacs और Vim में पहले से ही advanced IDE फीचर्स थे; LSP और tree-sitter की वजह से अब editor और language दोनों के लिए standardization आसान हो गई है।
    • मैं Emacs और Vim को niche editor कहे जाने से सहमत नहीं हूँ; ये पहले से ही प्रमुख editors हैं।
  • Emacs के बारे में मेरा लंबा time से belief रहा है कि यह AI एजेंट के लिए सबसे बेहतर editor है; एजेंट editor की पूरी state आसानी से देख सकता है और elisp से व्यवहार तक बदल सकता है। Vim/Emacs-स्तर की customization अनुमति देने वाले editor भविष्य में भी बड़ा advantage रखते हैं।
    • Vim और Emacs में वास्तव में हमेशा बड़ा strength रहा है; हर किसी का अलग take है। लेकिन निजी तौर पर VSCode और IntelliJ की बंद extensibility मुझे सबसे बड़ी कमजोरी लगती है—यानी सीमित plugin API, sandbox execution model, कंपनी-आधारित approval structure और अंदरूनी logic की opacity। पहले मैं नई फीचर्स की खोज में IDE बदलता रहता था, लेकिन अब लगता है कि सिर्फ Emacs सीखना ही मेरे काम के करीब ज्यादा ले जाता है। Emacs के साथ problem-solving का तरीका IDE की तुलना में कहीं अधिक satisfying है।
    • Emacs की असली ताकत उसके Lisp interpreter core में है: AI एजेंट रनटाइम में वही evaluation mechanism इस्तेमाल करके पूरी editor state सीधे inspect और बदल सकता है, जैसा user करता है। बाकी अधिकतर editors में plugin API काफी कठोर और fixed होती है।
  • मैं claude-code.el plugin का उपयोग करके खुश हूँ; यह pure terminal wrapper होते हुए भी मजबूत Transient menu देता है। सिर्फ Emacs के अंदर चलाने पर भी workflow efficiency काफी बढ़ गई। पुराने iTerm सेटअप की तुलना में मैंने कहीं आसान और ज्यादा customized flow बना लिया। आगे आने वाले नए packages पर भी मैं नजर रखूँगा; eca-emacs भी देख रहा हूँ। जो भी tools productivity के लिए critical हों, उनके साथ मैं शुरुआत में हमेशा cautious रहता हूँ क्योंकि सामान्यतः बड़ी projects में काफी polishing की जरूरत वाला 'big bang' phase आता है।
    • थोड़ा समय इस्तेमाल करने के बाद मैं फिर सिर्फ terminal में claude code पर वापस आ गया; Emacs में थोड़ा laggy लगा, और अलग terminal window रखने का कोई खास कारण नहीं दिखा। mcp.el package के साथ integration न होना भी अफ़सोस की बात है। वास्तव में काम के समय claude code से अभी तक मेरे काम के लायक code quality नहीं मिल पाई। mcp.el भी देखने लायक है।
  • Emacs में LSP, tree-sitter और Claude Code जैसे नए tools integrate होना देखकर खुशी है, लेकिन सेटअप का difficulty level भी सच में ऊपर गया लगता है। 20 साल पुराने Emacs user होने के बावजूद आजकल environment सेट करना आसान नहीं। Claude Code, IDE integration से पहले शायद सबसे आसान था (बस चलता था और auto buffer sync से संभालने को कुछ खास नहीं था)। नए MacOS पर typescript-ls किसी तरह चला, मगर gopls अभी तक download नहीं हो रहा। एक-दो घंटे मिलें तो ठीक हो सकता है, लेकिन issue कहाँ फँस रहा है खोजने में काफ़ी hassle होता है। हाल के Emacs users क्या कर रहे हैं, इसलिए share कर रहा हूँ। अभी मैं Zed पर काफी मज़े से कोड कर रहा हूँ; 20 साल की Emacs adaptation छोड़ना आसान नहीं। छोटे config edits से लेकर बड़े project support और extreme customization तक Emacs का value अभी भी अलग है। Neovim शायद इस दिशा में बेहतर हो, यह भी देखना चाहता हूँ। क्या मुझे elisp debugging और बेहतर सीखनी चाहिए ताकि समझ सकूँ कि जो commands मैं चलाता हूँ वे environment में कैसे काम करती हैं। इतने लंबे समय से Emacs keybindings (Dvorak तक) की आदत है, इसलिए Neovim experience अलग होगा या नहीं, इसका भी थोड़ा डर है।
    • elisp debugging मैं पूरी सिफारिश करूँगा। कई दशकों से Emacs चलाने के बाद भी कई लोगों को built-in profiler, edebug, apropos, macro expansion, advising system और indirect buffer जैसी चीज़ें नहीं पता होतीं। अगर Emacs को एक car से तुलना करें तो यह चलते-चलते parts बदलकर उसे submarine तक बना देने वाली machine है—इसलिए basic problem-solving और unexpected situations को accept करने का mindset जरूरी है। issue point तुरंत पहचानकर gptel buffer से सीधे hook या advise function के हिसाब से elisp लिखकर तुरंत test कर सकते हैं, और वो freedom खुद महसूस करनी पड़ती है। आजकल मैं 'clean' config maintenance पर ध्यान नहीं देता; बस modules ठीक से अलग रखता हूँ और जरूरत के हिसाब से elisp जोड़ता हूँ। अक्सर external कारणों—जैसे किसी अन्य package अपडेट—से breakage होता है, और सच में उसे खोजकर alternative तैयार करने में कुछ ही मिनट लगते हैं; ऐसा अक्सर कम ही होता है।
    • environment issues को आसान करने के लिए मैं Emacs को Docker environment में चला रहा हूँ; emacs-native-dockerfiles देखें।
    • Emacs में नए language ecosystems जोड़ना आसान नहीं क्योंकि package और बाहरी tools (LSP servers आदि) चुनना ही cumbersome है; कई dabbling projects भी हैं जिससे हर बार नया decision लेना पड़ता है। बाहर के tools को download/install करने में मैं Nix (devenv.sh), direnv आदि इस्तेमाल कर रहा हूँ ताकि Emacs खुद डाउनलोड न करे, सिर्फ paths सेट हों। संबंधित config files भी devenv में रख देता हूँ ताकि team के सभी लोग same environment चला सकें।
    • मैं 8 साल का Emacs user होने के बाद भी दो महीने पहले पूरी तरह nvim पर चला गया था और पूरे एक महीने Emacs नहीं खोला। अब lazy.vim install करके AI plugins को alternate करके चला रहा हूँ। nvim की ecosystem और community मुझे पिछले कुछ समय में उल्टा ज्यादा active लगी है; ThePrimeagen भी देखे जाने लायक हैं।
    • Neovim का experience भी काफी आगे बढ़ गया है—bare-bone से लेकर पूरी IDE functionality तक अलग-अलग सेटअप किया जा सकता है। पहले से pre-configured distributions भी काफी हैं, इसलिए lazy.vim जैसी चीज़ें देखें, जैसे कि LazyVim। AI plugins के लिए awesome-neovim #ai भी देखें।
  • org mode के साथ और मजबूत integration, या overall note-taking AI features की और ज्यादा जरूरत महसूस हो रही है। github/copilot 30 दिन के बाद chats हटा देता है, इसलिए AI से knowledge base बनाने में बड़ा friction आता है—यह मैं खुद देख चुका हूँ। Google के notebookllm की तरह शोध और नोट्स को local में सीधे manage करने वाला तरीका बेहद जरूरी लगता है।
    • gptel-mode इस्तेमाल करने की सलाह दूँगा; chat सीधे org buffer में save होते हैं, और session को आसानी से save/restore कर सकते हैं। mcp.el के साथ भी अच्छी integration देता है।
    • ob-aider भी देखने लायक है: ob-aider
  • mcp server में किसी भी नए tool को जोड़ने की सुविधा मुझे बेहद पसंद आई—पूरी तरह Emacs-style अपेक्षा पर खरी। कुछ सालों से use करते हुए मैं अब Elisp ज़्यादा सीधे लिखने लगा हूँ, और Claude का Elisp लिखने में support काफ़ी अच्छा है, इसलिए मैं इसे ज्यादा इस्तेमाल कर रहा हूँ (कभी-कभी bracket alignment खुद ठीक करनी पड़ती है, लेकिन कुल मिलाकर ठीक है)। Steve Yegge का efrit निश्चित रूप से देखूँगा: efrit। किसी agent के लिए कोई भी Elisp expression लिखना और execute करने देना Emacs की सीमाओं को एक और स्तर ऊपर ले जाता है।
    • मैं Yegge का पुराना fan और follower हूँ; अभी इसे अभी भी vibe code honeymoon stage ही कहूँगा, लेकिन Emacs expertise में कोई उसे पीछे नहीं छोड़ सकता। लगभग 1-2 साल पहले समझ आया कि बड़े LLMs का Elisp पर अजीब तरह से मजबूत होना ही hypermodern project की शुरुआत बना। efrit मुझे काफी promising लगता है, भले अभी पूरी तरह सेटअप नहीं कर पाया हूँ।
  • साथ में 5 से ज़्यादा Emacs/Claude Code integration packages आ चुके हैं और दो-तीन तो Reddit आदि पर काफ़ी aggressively compete कर रहे हैं—यह देखना रोचक है। लेकिन असली अच्छे plugins शायद चुपचाप मौजूद हैं और कोई ज़िक्र नहीं करता; yuya373/claude-code-emacs package लगभग सभी competitors के फीचर्स पहले ही implement कर चुका है।
    • कितनी popularity है नहीं पता, पर install करने में शायद यह सबसे आसान लगता है; melpa claude-code देखें।
    • इस package में शायद Claude-code-ide का /ide integration नहीं है।
  • eca को जरूर ज़रूर try करने की सलाह दूँगा; यह Emacs में AI pair programming का best tool बनाने पर focus कर रहा है।
  • हाल में Emacs community में ऐसा महसूस हुआ कि खुद AI integration के इन discussions को लेकर काफी criticism है, लेकिन नुकसान फायदे से ज्यादा है। AI चाहे इस generation की तरह अलग तरीके से evolve करे, Emacs की जड़ें MIT AI Lab में हैं—इसलिए उसी से निकले AI working group के tools के साथ AI integration से दूरी बनाना अजीब लगता है।
    • Emacs की खूबसूरती user-centric control में है; क्योंकि Elisp layer से चाहो तो जो चाहो बदल सकते हो, यही कारण है कि ऐसे packages लगातार आते हैं। इसके उलट VS Code structural split बनाता है: Microsoft अपने proprietary tools के लिए dedicated API रखता है और बाहर सिर्फ सीमित extension APIs देता है, इसलिए कई vscode forks बन गए। Emacs में अगर कोई भी बहुत skilled Elisp developer हो तो सब बदल सकता है और नए AI/LLM integration modules आसानी से आ सकते हैं। Emacs community की आलोचना शायद थोड़ा exaggerated है, क्योंकि वास्तविकता यह है कि AI/LLM plugins लगातार आ रहे हैं और अच्छी प्रतिक्रिया ले रहे हैं—उदाहरण के लिए gptel।
    • यह माहौल शायद Richard Stallman के कारण भी है; उनका मानना था कि free software project तैयार न हो तो 'proprietary software' alternatives को integrate करने पर सावधानी रखनी चाहिए। इस रवैये की वजह से GCC extensions, LLVM debugger, tree-sitter, git/bzr, CI buildfarm जैसे कई फैसलों में adoption delay हुआ, और बीच के समय Emacs जैसे core projects के substitutes adopt करने की गति धीमी रही; आखिरकार हमें हमेशा बाद में ही accept करना पड़ा। कभी-कभी यह FSF की जगह/डोमेन बचाने की कोशिश जैसा भी दिखा।
    • Emacs community बहुत diverse है; जहाँ भी जाओ कुछ criticism मिल ही जाएगा। फिर भी उसे ज्यादा गंभीरता से लेने की जरूरत नहीं क्योंकि तीसरे पक्ष के modules से जो चाहो add कर सकते हैं और core maintainer के पास रोकने का कोई तरीका नहीं।
    • MIT AI Lab का आधुनिक AI boom से जुड़ा होना नई information थी और काफी दिलचस्प लगा।
  • ये tools लेकर मैं बहुत excited हूँ और Emacs + AI को coding flow में डालना मुझे पसंद है; लेकिन सबसे बड़ा लक्ष्य अभी भी यही है कि इसे $2000 से कम के computer hardware पर पूरी तरह स्थानीय तौर पर चलाया जाए। क्या यह अभी या करीब भविष्य में संभव है? क्या कोई खुद local मॉडल्स से coding agent चला रहा है?
    • memory-efficient inference और ओपन-सोर्स, कोड-केंद्रित मॉडल में अब तक बहुत बड़ा progress हुआ है; अभी Qwen3-Coder मॉडल परिवार पर काफी focus है: Qwen3-Coder। स्थानीय रन के लिए Ollama, LM Studio जैसे tools मौजूद हैं। मॉडल साइज/quantization पर निर्भर करता है, पर $2000 budget में बहुत सारे मॉडल चला सकते हैं। M-series Macs भी value-wise अच्छे विकल्प हैं। local LLM उपयोग की जानकारी के लिए LocalLlamas subreddit में बहुत कुछ है। बड़े AI research labs के स्तर से फर्क रहेगा, लेकिन अगर कोई पूरी तरह local setup पसंद करता है तो यह एक काफी interesting और try करने लायक project है।
    • gptel local समेत कई models को support करता है।
    • MacMini, frame.work desktop, या Nvidia DGX Spark भी options हैं (lowest लगभग $3k).