Migrando do lsp-mode para o Eglot no GNU Emacs

• Partes de Wandering Thoughts e CSpace exibem uma página de bloqueio quando um User-Agent de navegador antigo aciona regras anti-crawler
• No início de 2025, os crawlers em massa aumentaram, e alguns parecem ter como objetivo a coleta de dados para treinamento de LLM, usando User-Agents antigos do Chrome
• Para reduzir a carga no site, está sendo testado o bloqueio de User-Agents de navegadores antigos, e usuários legítimos também podem ser afetados por falsos positivos
• Se o bloqueio ocorrer mesmo em um navegador atual, é possível entrar em contato pela página pessoal da Universidade de Toronto, enviando o navegador usado e a string exata do User-Agent
• A família archive.* é difícil de distinguir por usar User-Agents antigos do Chrome e IPs distribuídos, então para o arquivo de Wandering Thoughts é recomendado o archive.org

---

Por que a página de bloqueio é exibida

• Ao acessar Wandering Thoughts ou partes de CSpace, uma página de bloqueio é exibida se a versão do navegador for classificada como suspeita pelas regras anti-crawler do site
• No início de 2025, os crawlers em massa aumentaram, e alguns parecem ter como objetivo a coleta de dados para treinamento de LLM, usando vários User-Agents de navegadores antigos, incluindo User-Agents antigos do Chrome
• Está em andamento um experimento para bloquear User-Agents de navegadores antigos a fim de reduzir a carga no site, e usuários legítimos também podem acabar atingidos por essa regra
• Se você usa um navegador atual e ainda assim é bloqueado, pode entrar em contato pela página pessoal da Universidade de Toronto e, se possível, enviar também o navegador em uso e a string exata do User-Agent

Observações por tipo de usuário

• Usuários do Inoreader

  • O coletor de feeds do Inoreader em si não é alvo do bloqueio e, de fato, continua buscando os feeds regularmente
  • O Inoreader pode buscar o feed ou a página usando um User-Agent HTTP de navegador antigo ou um navegador realmente antigo e, como resultado, mostrar ao usuário a página de bloqueio recebida
  • Os resultados mais recentes de requisições HTTP podem variar conforme o HTTP User-Agent utilizado; mais detalhes estão em HTTPResultsAndUserAgents

• Usuários do Vivaldi

  • Por causa do ataque em andamento, até o Vivaldi atual pode ser bloqueado se for identificado como Google Chrome
  • Talvez seja necessário alterar a configuração "User Agent Brand Masking" para que o Vivaldi seja identificado como Vivaldi, e não como Google Chrome

• Usuários de archive.*

  • Você pode ver essa página de bloqueio por meio de archive.today, archive.ph, archive.is etc.
  • O archive.* usa User-Agents antigos do Chrome, faz crawling a partir de blocos de IP amplamente distribuídos e alguns IPs têm entradas de DNS reverso falsificadas alegando ser IPs do googlebot, o que dificulta distingui-lo de agentes maliciosos
  • Para arquivar o Wandering Thoughts, recomenda-se usar o archive.org, cujo crawler de arquivamento funciona melhor

[GN⁺]

Opiniões no Lobste.rs

• Dependendo da linguagem, a recomendação de iniciar o Eglot automaticamente pode ser catastroficamente ruim. Os servidores LSP de muitas linguagens não são seguros para uso com código não confiável, e só de abrir os arquivos de um projeto Rust ou Elixir controlado por um atacante sua máquina pode ser comprometida
  A menos que seja uma linguagem com um servidor LSP conhecido por ser seguro, é melhor evitar a ativação automática do LSP. Referência: https://rust-analyzer.github.io/book/security.html

  • Se você vai inspecionar código potencialmente hostil, no fim das contas todo o trabalho precisa acontecer dentro de uma fronteira de segurança real. Até git status pode ampliar a superfície de ataque: https://github.com/justinsteven/advisories/…
    A diferença é que, no caso acima, o repositório em si precisa conter o exploit, enquanto no LSP o problema também pode vir do lado das dependências. Ainda assim, se você se acostuma a ligar o LSP por padrão, parece difícil evitar ficar dessensibilizado aos avisos
  • Outro motivo para evitar a inicialização automática é que alguns servidores de linguagem têm exigências altas de recursos. Em um projeto Rust de porte médio, só abrir um arquivo por alguns instantes já pode fazer um processo rust-analyzer de 4 GB rodar por vários minutos e criar um diretório target/debug/ com mais de 1 GB
  • De qualquer forma, no momento em que você roda cargo build, de certa forma já era. Claro, há uma grande diferença entre carregar o LSP automaticamente e um comando executado explicitamente pelo usuário, mas no uso real essa diferença talvez seja menor do que parece
  • Se você quer automação, é melhor fazer como o lsp-mode: perguntar antes de ativar e adicionar o projeto a uma lista de permissões. Se você já tem um hook que “executa automaticamente”, dá para fazer ele primeiro perguntar com read-from-minibuffer “você confia nesta pasta?” em umas 10 linhas, e usar algo como projectile para definir o diretório-base já traz a maior parte do ganho de segurança
    Minha configuração usa a lista de permissões do lsp-mode, mas a limpa a cada sessão, então sempre que reabro o Emacs preciso consentir de novo por projeto. Acho que originalmente fiz isso por desempenho, e houve casos em que o lsp-mode subia vários processos antes mesmo de eu abrir um projeto específico. O risco de segurança é real, mas não é tão difícil montar um fluxo de trabalho razoável

• O ponto mais irritante do Eglot é que ele não expõe a maioria dos comandos como funções e os define sobre interfaces do Emacs como xref. Em casos como Clojure, quando há backends xref tanto do CIDER quanto do clojure-lsp, acabo preferindo o lado do CIDER, que conhece o estado real em tempo de execução do código carregado
  A análise estática do clojure-lsp pode se dessincronizar, especialmente em fluxos de trabalho com REPL remota. No lsp-mode, você pode chamar diretamente comandos como ir para definição e continuar usando xref, mas no Eglot é bem trabalhoso excluir apenas um backend xref específico. Outros comandos presentes no lsp-mode também faltam no Eglot, embora na prática sejam recursos que poderiam ser oferecidos por pontos de integração do Emacs parecidos com xref

• Usei lsp-mode uma vez, mas apareceram tantos pop-ups e notificações confusas que removi na hora. O Eglot oferece uma experiência de LSP muito mais silenciosa
  Você pode deixá-lo ligado e usar os recursos quando estiver pronto. É interessante como ~cks aborda isso vindo da direção oposta e menciona várias dicas e alternativas

  • Eu desligo muitos recursos no lsp-mode e consigo usá-lo com uma interface bem silenciosa. Tentei migrar para o Eglot, mas não parecia ter as integrações que eu queria, então não fui muito além naquela época
    O que eu realmente queria encontrar é um servidor LSP capaz de lidar com repositórios muito grandes. Isso tem sido um limite frequente, e às vezes penso se eu deveria criar algo que processe a maior parte da indexação do código-fonte de uma vez e depois a reutilize para várias tarefas no estilo LSP, mas fico na dúvida se isso não seria tentar ferver outro oceano

• Eglot e lsp-mode são os clientes LSP para Emacs mais conhecidos, mas também existem alternativas como lspce e lsp-bridge
  Usei o Eglot com satisfação por vários anos, mas ele tem uma limitação de projeto que pode virar um problema maior no futuro. Ele assume um cliente por buffer; isso fazia sentido quando o Eglot foi criado, mas agora está ficando cada vez mais comum querer rodar vários servidores LSP em um único buffer. A [recomendação] atual é usar um programa separado como multiplexador de LSP

  • Para esse fim existe isto

• Há 4 dias migrei de lsp-mode para Eglot no Python e estou satisfeito
  Publiquei aqui uma versão mínima da configuração atual: https://discuss.afpy.org/t/configuration-emacs-minimale-en-2026/3001

  • Há quase um ano mudei de elpy para eglot + basedpyright, e também estou bem satisfeito
    Ainda assim, há alguns incômodos com autocompletar. Por exemplo, quando pressiono foo<tab><tab>, às vezes o basedpyright faz autoimport de alguma coisa estranha mesmo quando já existe um símbolo adequado no escopo atual, e ainda não encontrei uma forma de completar só até a maior substring comum. Fora isso, está bem bom

• Tenho inveja de quem consegue usar o Emacs como uma IDE moderna. Eu uso os atalhos do Emacs, mas mesmo investindo 6 a 8 horas nunca consegui fazê-lo funcionar como IDE
  No passado tentei ajustar tudo para FB Flow, que eu usava no lugar de TypeScript em ambientes de desenvolvimento Linux e FreeBSD, e desisti; no fim de semana passado tentei de novo montar um ambiente Python completo no Windows com tree-sitter, e desisti outra vez. Há coisa demais para configurar, e também é preciso baixar DLLs demais, como os parsers do tree-sitter, então o que é necessário para transformá-lo em uma IDE de verdade parece excessivo. Já não quero mais investir esse tempo, mas ainda gosto do fato de poder digitar emacs -nw em qualquer terminal e ter aquele ambiente de edição familiar

  • Para Python, dá para começar muito bem só com uma configuração mínima de fido-vertical-mode, which-key-mode, global-completion-preview-mode, yasnippet, eglot-ensure e basedpyright
    Se o basedpyright estiver no PATH, você terá autocompletar e destaque de sintaxe decentes mesmo sem gramática tree-sitter. Isso é uma versão reduzida ao mínimo da minha configuração completa, e a configuração inteira está em my full config
  • Vale a pena experimentar o doom emacs. A configuração é muito fácil e, no estado padrão, a maior parte das coisas já funciona bem. Se você não gostar do evil-mode, também pode voltar para os atalhos do Emacs