GNU Emacs में lsp-mode से Eglot पर जाना

 (utcc.utoronto.ca)
1 पॉइंट द्वारा GN⁺ 1 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Wandering Thoughts और CSpace के कुछ हिस्से पुराने browser User-Agent पर block page दिखाते हैं, जब वह crawler-रोधी नियमों में फंस जाता है
  • 2025 की शुरुआत में बड़े पैमाने पर crawlers बढ़े, और कुछ का उद्देश्य LLM training के लिए data collection जैसा दिखता है; ये पुराने Chrome User-Agent का उपयोग करते हैं
  • site load कम करने के लिए पुराने browser User-Agent को block करने का प्रयोग चल रहा है, और इसमें सामान्य users भी false positive के रूप में फंस सकते हैं
  • अगर latest browser में भी block हो रहा है, तो Toronto University के personal page के जरिए संपर्क किया जा सकता है, और browser तथा सटीक User-Agent string भेजनी चाहिए
  • archive.* श्रृंखला को पुराने Chrome User-Agent और distributed IPs की वजह से अलग पहचानना मुश्किल है, इसलिए Wandering Thoughts archive के लिए archive.org की सिफारिश की जाती है

block page क्यों दिखता है

  • Wandering Thoughts या CSpace के कुछ हिस्सों तक पहुंचते समय, अगर browser version को site के crawler-रोधी नियम संदिग्ध मानते हैं, तो block page दिखाया जाता है
  • 2025 की शुरुआत तक बड़े पैमाने पर crawlers बढ़ गए हैं, और कुछ LLM training के लिए data collection जैसे लगते हैं; वे पुराने Chrome User-Agent सहित कई पुराने browser User-Agent का उपयोग करते हैं
  • site load कम करने के लिए पुराने browser User-Agent को block करने का प्रयोग चल रहा है, और सामान्य users भी इन नियमों में फंस सकते हैं
  • अगर आप latest browser इस्तेमाल कर रहे हैं और फिर भी block हो रहे हैं, तो Toronto University personal page के जरिए संपर्क किया जा सकता है, और संभव हो तो उपयोग में लिया जा रहा browser तथा सटीक User-Agent string साथ में भेजनी चाहिए

user के अनुसार ध्यान देने योग्य बातें

  • Inoreader users

    • Inoreader का feed fetcher खुद block target नहीं है, और वास्तव में feeds नियमित रूप से fetch कर रहा है
    • Inoreader पुराने browser HTTP User-Agent या सचमुच पुराने browser से feed या page fetch करने के बाद, उसके परिणामस्वरूप मिला block page user को दिखा सकता है
    • latest HTTP request result इस्तेमाल किए गए HTTP User-Agent के अनुसार बदल सकते हैं; संबंधित जानकारी HTTPResultsAndUserAgents में है

  • Vivaldi users

    • चल रहे attack की वजह से latest Vivaldi भी अगर Google Chrome के रूप में पहचाना जाए तो block हो सकता है
    • Vivaldi को Google Chrome नहीं बल्कि Vivaldi के रूप में पहचानने के लिए "User Agent Brand Masking" setting बदलनी पड़ सकती है

  • archive.* users

    • archive.today, archive.ph, archive.is आदि के जरिए यह block page दिख सकता है
    • archive.* पुराने Chrome User-Agent का उपयोग करता है, बहुत फैले हुए IP blocks से crawling करता है, और कुछ IPs में googlebot IP होने का दावा करने वाली forged reverse DNS entries होती हैं, इसलिए इसे malicious actors से अलग करना कठिन है
    • Wandering Thoughts को archive करना हो, तो बेहतर काम करने वाले archive crawler archive.org का उपयोग करने की सिफारिश की जाती है

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

1 टिप्पणियां

 
GN⁺ 1 시간 전
Lobste.rs की रायें

  • कुछ भाषाओं में Eglot को ऑटो-स्टार्ट करने की सलाह बेहद ख़तरनाक हो सकती है। कई भाषाओं के LSP सर्वर untrusted code के साथ सुरक्षित रूप से इस्तेमाल नहीं किए जा सकते, और attacker के नियंत्रण वाले Rust या Elixir प्रोजेक्ट की फ़ाइल सिर्फ़ खोलने भर से भी मशीन compromise हो सकती है
    अगर भाषा के लिए कोई ऐसा LSP सर्वर नहीं है जिसे सुरक्षित माना जाता हो, तो LSP auto-activation से बचना चाहिए। संदर्भ: https://rust-analyzer.github.io/book/security.html

    • अगर आप संभावित रूप से hostile code देख रहे हैं, तो आख़िरकार पूरा काम वास्तविक security boundary के भीतर ही करना चाहिए। git status भी attack surface बन सकता है: https://github.com/justinsteven/advisories/…
      फ़र्क बस इतना है कि ऊपर वाले मामले में exploit repository के भीतर होना चाहिए, जबकि LSP में dependency side से भी समस्या आ सकती है। फिर भी अगर आदतन LSP चालू रखने की आदत पड़ जाए, तो warnings के प्रति सुस्त न होना मुश्किल लगता है
    • ऑटो-स्टार्ट से बचने की एक और वजह कुछ language servers की resource requirements हैं। मध्यम आकार के Rust प्रोजेक्ट में सिर्फ़ थोड़ी देर के लिए फ़ाइल खोलने पर भी 4GB का rust-analyzer process कई मिनट तक चल सकता है, और 1GB से बड़ा target/debug/ directory बन सकता है
    • वैसे cargo build चलाते ही मामला काफ़ी हद तक वैसा ही हो जाता है। बेशक LSP auto-load और user द्वारा साफ़ तौर पर चलाया गया command में बड़ा अंतर है, लेकिन व्यवहार में यह अंतर सोचे से कम भी हो सकता है
    • अगर automation चाहिए, तो lsp-mode की तरह activation से पहले पूछना और project को allowlist में जोड़ना बेहतर है। अगर पहले से कोई “अपने आप चलने” वाला hook है, तो read-from-minibuffer से पहले “क्या आप इस folder पर भरोसा करते हैं?” पूछने लायक बनाना लगभग 10 lines में हो सकता है, और projectile जैसी चीज़ से base directory तय कर लें तो सुरक्षा के ज़्यादातर फ़ायदे मिल जाते हैं
      मेरी setup lsp-mode की allowlist का इस्तेमाल करती है, लेकिन हर session में उसे साफ़ कर देती है, ताकि Emacs दोबारा खोलने पर हर project के लिए फिर से सहमति देनी पड़े। लगता है मैंने मूल रूप से यह performance की वजह से किया था, क्योंकि lsp-mode कभी-कभी किसी खास project को खोलने से पहले ही कई processes शुरू कर देता था। सुरक्षा जोखिम वास्तविक है, लेकिन ठीक-ठाक workflow बनाना बहुत मुश्किल भी नहीं है

  • Eglot में सबसे परेशान करने वाली बात यह है कि यह ज़्यादातर commands को functions के रूप में expose नहीं करता, बल्कि उन्हें xref जैसे Emacs interfaces के ऊपर define करता है। Clojure जैसी स्थिति में, जहाँ CIDER और clojure-lsp दोनों के xref backend मौजूद हों, वहाँ आम तौर पर CIDER को प्राथमिकता मिलती है क्योंकि वही loaded code की असली runtime state जानता है
    clojure-lsp का static analysis ख़ासकर remote REPL workflow में sync से बाहर हो सकता है। lsp-mode में go to definition जैसी features को command के रूप में सीधे call करते हुए भी xref इस्तेमाल किया जा सकता है, लेकिन Eglot में किसी खास xref backend को हटाना काफ़ी झंझट भरा है। lsp-mode के दूसरे commands भी Eglot में नहीं हैं, जबकि वे असल में xref जैसे Emacs integration points के ज़रिए दिए जा सकते हैं

  • मैंने lsp-mode एक बार इस्तेमाल किया था, लेकिन उसमें इतने उलझाऊ popups और notifications आते थे कि मैंने तुरंत हटा दिया। Eglot एक कहीं ज़्यादा शांत LSP अनुभव देता है
    इसे चालू रहने दें और जब तैयार हों तब features इस्तेमाल करें। ~cks का उलटी दिशा से आना और रास्ते में अलग-अलग tips व alternatives बताना दिलचस्प लगा

    • मैं lsp-mode में कई features बंद करके उसे काफ़ी शांत interface की तरह इस्तेमाल कर रहा हूँ। Eglot पर जाने की कोशिश की थी, लेकिन उसमें वह integration नहीं दिखा जो मैं चाहता था, इसलिए तब आगे कोशिश नहीं की
      मैं सच में ऐसा LSP server चाहता हूँ जो बहुत बड़े repositories संभाल सके। यही चीज़ बार-बार सीमा बनकर सामने आई है, और कभी-कभी लगता है कि शायद ऐसा कुछ बनाना पड़े जो source indexing ज़्यादातर एक बार में कर ले और फिर उसे कई LSP-स्टाइल कामों में reuse करे, लेकिन डर है कि कहीं यह फिर एक और बहुत बड़ा काम न बन जाए

  • Emacs के लिए LSP clients में Eglot और lsp-mode सबसे मशहूर हैं, लेकिन lspce और lsp-bridge जैसे alternatives भी हैं
    मैं कई सालों से Eglot संतोष के साथ इस्तेमाल कर रहा हूँ, लेकिन इसमें एक design limitation है जो आगे और बड़ी समस्या बन सकती है। यह प्रति buffer एक client मानकर चलता है; जब Eglot बनाया गया था तब यह उचित था, लेकिन अब एक ही buffer में कई LSP servers चलाने की ज़रूरत बढ़ती जा रही है। मौजूदा recommendation है कि किसी अलग program को LSP multiplexer की तरह इस्तेमाल किया जाए

    • उसके लिए this मौजूद है

  • 4 दिन पहले मैंने Python के लिए lsp-mode से Eglot पर स्विच किया और संतुष्ट हूँ
    अपनी मौजूदा configuration का एक minimal version यहाँ सार्वजनिक किया है: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

    • लगभग एक साल पहले मैंने elpy से eglot + basedpyright पर स्विच किया था, और मैं भी काफ़ी संतुष्ट हूँ
      हाँ, completion को लेकर कुछ असुविधा है। उदाहरण के लिए foo<tab><tab> दबाने पर, जबकि current scope में सही symbol मौजूद हो, basedpyright कभी-कभी कोई अजीब auto-import कर देता है, और अभी तक मुझे ऐसा तरीका नहीं मिला जो सिर्फ़ सबसे लंबी common string तक completion करे। इसके अलावा यह काफ़ी अच्छा है

  • मुझे उन लोगों से जलन होती है जो Emacs को modern IDE की तरह इस्तेमाल कर लेते हैं। मैं Emacs key bindings इस्तेमाल करता हूँ, लेकिन 6–8 घंटे लगाने पर भी Emacs को IDE की तरह काम नहीं करा पाया
    पहले Linux और FreeBSD development environment में TypeScript की जगह इस्तेमाल होने वाले FB Flow के हिसाब से सेट करने की कोशिश की थी और छोड़ दिया, और पिछले वीकेंड Windows पर tree-sitter के साथ एक full-featured Python environment बनाने की कोशिश की, वह भी छोड़नी पड़ी। सेट करने के लिए बहुत कुछ है, और tree-sitter parsers जैसी DLLs भी अलग से बहुत डाउनलोड करनी पड़ती हैं, इसलिए इसे एक ढंग का IDE बनाने के लिए ज़रूरत से ज़्यादा चीज़ें चाहिए। अब मैं इसमें समय नहीं लगाना चाहता, लेकिन कभी-कभी किसी भी terminal में emacs -nw चलाते ही परिचित editing environment मिल जाना अच्छा लगता है

    • अगर Python है, तो fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure, basedpyright जैसी minimal configuration से शुरुआत करना काफ़ी है
      अगर basedpyright path में उपलब्ध है, तो tree-sitter syntax के बिना भी ठीक-ठाक completion और syntax highlighting मिल जाती है। यह मेरी पूरी setup का न्यूनतम किया हुआ version है, और पूरी setup my full config में है
    • doom emacs आज़माने लायक है। इसे configure करना बहुत आसान है और default state में भी ज़्यादातर चीज़ें ठीक चलती हैं। अगर evil-mode पसंद न आए तो Emacs key bindings पर वापस भी जा सकते हैं