Emacs-copilot: conclusão de código por modelo de linguagem grande para Emacs

Artigo original ↗ Discussão no Hacker News ↗

Usuários de Emacs estão reagindo a um novo plugin “emacs-copilot” que traz conclusão de código no estilo GitHub Copilot para o editor usando modelos de linguagem grande executados localmente via a pilha llamafile/llama.cpp da Mozilla. Os comentaristas avaliam os benefícios de modelos auto-hospedados para privacidade, controle e desempenho em comparação com APIs na nuvem, e debatem estilos de interação como conclusões sob demanda versus conclusões constantemente empurradas. O projeto também levanta preocupações sobre conflitos de nome com clientes Copilot já existentes para Emacs, possíveis questões de marca registrada da Microsoft em torno de “Copilot” e o modelo de segurança de distribuir pacotes de modelo executáveis em vez de arquivos de pesos simples.

Nomeação, marcas registradas e confusão

  • O nome do pacote “copilot” é confuso porque o Emacs já tem um cliente GitHub Copilot com um nome semelhante.
  • Vários comentários discutem se “Copilot” é ou pode ser uma marca registrada da Microsoft e como isso se cruza com o uso genérico.
  • Alguns argumentam que tudo bem, desde que não haja intenção de confundir usuários ou lucrar com a confusão da marca; outros antecipam pressão jurídica de qualquer forma.

Arquitetura, llamafile e desempenho

  • O pacote usa llamafile (llama.cpp dentro de um “executável realmente portátil”) para executar modelos locais.
  • O carregamento baseado em mmap evita recarregar totalmente o modelo a cada vez; a primeira conclusão em um arquivo é mais lenta, as seguintes são muito mais rápidas graças a um cache ao lado do arquivo.
  • Modelos grandes (por exemplo, 34B) são utilizáveis, mas lentos; modelos menores quantizados como WizardCoder 13B ou Phi-2 rodam de forma aceitável em máquinas de faixa média.
  • Atualizar o llamafile não exige estritamente baixar novamente os pesos; usuários podem extrair pesos GGUF e reempacotá-los em um novo binário ou apontar um llamafile genérico para pesos externos com -m.

Local vs remoto / auto-hospedado vs nuvem

  • Há forte entusiasmo por LLMs auto-hospedados para evitar enviar código para OpenAI/Microsoft e para manter o controle.
  • Alguns querem executar modelos em servidores na LAN ou via SSH; exemplos usando ssh com call-process e as APIs HTTP do llamafile são discutidos.
  • Outros observam que ferramentas existentes como ollama e o servidor do llama.cpp já fornecem endpoints no estilo OpenAI com streaming.

UX: conclusões sob demanda vs inline

  • Alguns usuários preferem o estilo GitHub Copilot: sugestões inline em cinza aparecendo automaticamente.
  • Outros detestam fortemente conclusões “push”, achando-as distrativas; preferem interações explícitas de “pense quando eu pedir” e poder interromper o streaming.
  • Há concordância de que a configurabilidade entre os modos push/pull seria o ideal.

Ecossistema e alternativas

  • Vários pacotes de LLM para Emacs são mencionados: gptel, ellama, modos relacionados ao chatgpt, llm.el, ferramentas integradas ao org e um cliente GitHub Copilot.
  • Para Vim/Neovim, usuários mencionam gp.nvim, gen.nvim e comandos personalizados; alguns fazem forks de plugins para combinar modelos locais (ollama) e remotos.

Segurança e confiança

  • Alguns desconfiam de llamafiles executáveis em vez de arquivos “burramente” de pesos de modelo, traçando analogias com formatos pickle inseguros.
  • Outros respondem que o llamafile é apoiado por uma organização respeitável e também pode ser usado com pesos GGUF externos; os modelos de ameaça diferem.

Problemas de configuração e plataformas

  • Vários usuários em macOS e Asahi Linux encontram vfork: Exec format error quando o Emacs lança o llamafile.
  • Soluções alternativas incluem usar um interpretador “ape”, converter llamafiles em binários nativos com “assimilate”, ou executar um Emacs ligado ao Cosmo.

Debate sobre a utilidade de LLMs

  • Alguns estão entusiasmados, especialmente para Lisp e trabalho pesado em boilerplate (por exemplo, React moderno).
  • Outros argumentam que revisar e validar a saída do LLM anula ganhos de produtividade para código de produção de alta qualidade, e se preocupam com desenvolvedores transferindo responsabilidade (“foi o modelo que escreveu”).