Como evito linhas extremamente longas, tornando o Emacs lento?

Vejo um desempenho extremamente variado, dependendo de quantas novas linhas existem no arquivo que estou visitando.

Aqui está um exemplo. Eu tenho dois arquivos JSON:

$ wget https://github.com/Wilfred/ReVo-utilities/blob/a4bdc40dd2656c496defc461fc19c403c8306d9f/revo-export/dictionary.json?raw=true -O one_line.json
$ python -m json.tool <one_line.json >pretty_printed.json

Estes são dois arquivos JSON com o mesmo conteúdo. one_line.jsontem 18MiB de JSON sem novas linhas. pretty_printed.jsonadicionou novas linhas e espaços em branco, tornando-o 41MiB.

No entanto, o arquivo maior dividido em muitas linhas é muito mais rápido para abrir no Emacs, tanto no modo Javascript quanto no modo Fundamental.

Por que o Emacs tem um desempenho tão ruim com longas filas, já que na verdade são menos bytes? Há algo que eu possa fazer para melhorar o desempenho sem reformatar os dados fora do Emacs?

O manuseio de linhas longas da Emacs não é muito bem otimizado. Para várias operações, o Emacs precisa varrer toda a linha repetidamente. Por exemplo, para exibir uma linha, o Emacs precisa descobrir a altura da linha, o que requer a varredura de toda a linha para encontrar o glifo mais alto. Além disso, a digitalização para exibição bidirecional consome muito tempo. Você pode obter algumas informações adicionais, por exemplo, na sequência de documentos de cache-long-line-scans(renomeada cache-long-scansem 24.4).

Você pode tentar e ver se a configuração bidi-paragraph-directionpara left-to-rightmelhora a velocidade para você [definindo bidi-display-reorderinga nil, faz mais ou menos o mesmo, mas destina-se apenas para fins / depuração internas]. Isso remove um colaborador significativo das varreduras de linha, mas infelizmente não é o único.

A melhor opção é adicionar novas linhas. Você pode canalizar um arquivo JSON, por exemplo, python -c 'import json, sys ; json.dump(json.load(sys.stdin), sys.stdout, indent=2)'para adicionar novas linhas e melhorar a legibilidade em geral.

Fiz algumas breves experiências com isso usando uma cópia minificada do jquery. font-lock-modee flycheck-modeambos contribuíram para a lentidão, como fizeram js2-mode, e prettify-symbols-mode. line-number-modee column-number-modeteve efeito menor. Uma vez eu desliguei todos os modos diferentes, embora o desempenho fosse relativamente rápido. Use C-h me comece a desativar os diferentes modos que estão habilitados ou tente apenas mudar para fundamental-mode.

Curiosamente, hexl-modeeu poderia voar através do arquivo sem nenhum problema, embora obviamente as colunas fossem bem curtas. Infelizmente, visual-line-moderealmente diminuiu as coisas.

Meu palpite é que a tabela de sintaxe fica feliz em parar o processamento nas terminações de linha e, quando tudo está em uma linha, ele deve revisar tudo a cada atualização.

Fiz upload de http://www.emacswiki.org/emacs/OverLongLineMode

Essa biblioteca permite definir limites simples de comprimento de linha além dos quais uma variante de fundamental-modeserá usada para um arquivo em vez de seu modo normal (apenas para modos de programação).

Potencialmente, algo nesse sentido poderia ser adicionado ao Emacs por padrão, mas isso pode ser uma solução provisória para o problema principal do Emacs que fica lento ao rastrear ao encontrar esse arquivo.

Nota: isso é uma melhoria no código que eu postei inicialmente nesta resposta, mas ainda é um trabalho em andamento. Os testes foram mínimos. Comentários são bem-vindos.

Sugestões para outros (além css-mode) prog-modemodos principais não derivados para suporte por padrão também são bem-vindas.

Espero que você descubra que a diferença se deve a isso font-lock. Quando a fonte é executada no subconjunto do arquivo visível na janela, ela prossegue estendendo primeiro a região da fonte, de forma a incluir unidades semânticas completas. Veja o font-lock-extend-region-functionscódigo para isso. É comum que isso inclua a extensão da região para incluir linhas completas. Quando as linhas são extremamente longas, isso pode fazer com que a fonte seja executada em um pedaço de conteúdo muito maior do que é realmente visível.

Além disso, quando as novas linhas possuem informações semânticas, sua ausência às vezes pode significar que os padrões de expressão regular para bloqueio de fonte precisam ser varridos ainda mais para determinar se são correspondentes ou não.

Normalmente, desenrolo linhas longas e recuo por tags (como HTML, XML, JSON).

Para possibilitar essa operação, adiciono:

(setq line-number-display-limit large-file-warning-threshold)
(setq line-number-display-limit-width 200)

(defun my--is-file-large ()
  "If buffer too large and my cause performance issue."
  (< large-file-warning-threshold (buffer-size)))

(define-derived-mode my-large-file-mode fundamental-mode "LargeFile"
  "Fixes performance issues in Emacs for large files."
  ;; (setq buffer-read-only t)
  (setq bidi-display-reordering nil)
  (jit-lock-mode nil)
  (buffer-disable-undo)
  (set (make-variable-buffer-local 'global-hl-line-mode) nil)
  (set (make-variable-buffer-local 'line-number-mode) nil)
  (set (make-variable-buffer-local 'column-number-mode) nil) )

(add-to-list 'magic-mode-alist (cons #'my--is-file-large #'my-large-file-mode))

Eu dividir linha de regex, para XML-lo: C-M-% >< RET >NL< RET !.

Depois que o Emacs divide as linhas longas - é possível ativar muitos *-modese re-recuar o código.

Nota: Como evitar a desaceleração quando um processo inferior gera longas filas?

Criei minha própria solução para esse problema aqui: https://github.com/rakete/too-long-lines-mode

Eu não estava satisfeito com a solução phils, que alterna um buffer com linhas muito longas para o modo fundamental; queria uma solução que me permitisse manter o destaque da sintaxe e outros recursos do modo principal. Então, criei um modo menor que usa sobreposições para ocultar a maioria dos caracteres de linhas muito longas.

Isso soluciona o problema e torna o emacs utilizável mesmo em buffers com linhas muito longas, sem precisar voltar ao modo fundamental.

Na minha configuração do Emacs, eu tenho um modo com fonte personalizada, ou seja, onde eu configuro font-lock-defaults. Uma única página para baixo usaria 30 segundos para exibir parte da linha de 30000 caracteres. Esse lentidão foi corrigido através da redução do retorno do regexp. Ao invés de:

  (". * terminou com um comando incompleto *" 0 font-lock-comment-face)

fazem isto

  ("^. \ {1,80 \} terminou com um comando incompleto *" 0 font-lock-comment-face)

Nos meus buffers de modo shell (shell Mx), eu me pego tentando sed -r 's/(.{2000}).*/\1/' -uevitar longas filas.

Eu uso a seguinte função para abrir dired-modearquivos grandes com linhas longas:

(defun dired-find-file-conservatively ()
   (interactive)
   (let ((auto-mode-alist nil))
     (dired-find-file)
     ;; disable costly modes
     (fundamental-mode)
     (setq-local bidi-display-reordering nil)
     (when (boundp 'smartparens-mode)
       (smartparens-mode -1))))

(define-key dired-mode-map (kbd "S-<return>") 'dired-find-file-conservatively)

Aqui está uma solução alternativa, retirada do emacs-devel :

(add-hook 'find-file-hook
          (defun my-find-file-care-about-long-lines ()
            (save-excursion
              (goto-char (point-min))
              (when (and (not (eq major-mode 'image-mode))
                         (search-forward-regexp ".\\{2000\\}" 50000 t)
                         (y-or-n-p "Very long lines detected - enable 
longlines-mode? "))
                (require 'longlines)
                (longlines-mode +1)))))