¿Cómo evito que las líneas extremadamente largas hagan que Emacs sea lento?

Veo un rendimiento muy variado dependiendo de cuántas líneas nuevas haya en el archivo que estoy visitando.

Aquí hay un ejemplo. Tengo dos archivos 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

Estos son dos archivos JSON con el mismo contenido. one_line.jsones 18MiB de JSON sin ninguna línea nueva. pretty_printed.jsontiene nuevas líneas y espacios en blanco agregados, lo que lo hace 41MiB.

Sin embargo, el archivo más grande dividido en muchas líneas es mucho más rápido de abrir en Emacs, tanto en modo Javascript como en modo Fundamental.

¿Por qué Emacs tiene un rendimiento tan pobre con líneas largas, ya que en realidad son menos bytes? ¿Hay algo que pueda hacer para mejorar el rendimiento sin reformatear los datos fuera de Emacs?

El manejo de Emacs de líneas largas no está muy bien optimizado. Para una serie de operaciones, Emacs tiene que escanear la línea completa repetidamente. Por ejemplo, para mostrar una línea, Emacs tiene que calcular la altura de la línea, lo que requiere escanear toda la línea para encontrar el glifo más alto. Además, el escaneo en busca de visualización bidireccional consume mucho tiempo. Puede obtener información adicional en, por ejemplo, la cadena de documentos de cache-long-line-scans(renombrada cache-long-scansen 24.4).

Puede intentar ver si la configuración bidi-paragraph-directionde left-to-rightmejora la velocidad para usted [la configuración bidi-display-reorderingde nil, hace más o menos lo mismo, pero solo está destinada a fines internos / de depuración]. Esto elimina un contribuyente significativo a los escaneos de línea, pero lamentablemente no es el único.

La mejor opción es agregar nuevas líneas. Puede canalizar un archivo JSON, por ejemplo, python -c 'import json, sys ; json.dump(json.load(sys.stdin), sys.stdout, indent=2)'para agregar nuevas líneas y mejorar la legibilidad en general.

Hice algunos experimentos breves con esto usando una copia minificada de jquery. font-lock-modey flycheck-modeambos contribuyeron a la lentitud, como lo hizo js2-mode, y prettify-symbols-mode. line-number-modey column-number-modetuvo un efecto menor. Una vez que apagué todos los modos diferentes, aunque el rendimiento fue relativamente rápido. Use C-h my comience a deshabilitar los diferentes modos que están habilitados, o intente simplemente cambiar a fundamental-mode.

Curiosamente hexl-mode, podría volar a través del archivo sin ningún problema, aunque obviamente las columnas eran bastante cortas. Desafortunadamente, visual-line-moderealmente ralentizó las cosas.

Supongo que la tabla de sintaxis se complace en detener el procesamiento en los finales de línea, y cuando todo está en una línea, tiene que volver a analizar todo en cada actualización.

He subido http://www.emacswiki.org/emacs/OverLongLineMode

Esta biblioteca le permite establecer umbrales simples de longitud de línea más allá de los cuales fundamental-modese utilizará una variante de para un archivo en lugar de su modo normal (solo para modos de programación).

Potencialmente, algo por el estilo podría agregarse a Emacs de forma predeterminada, pero esto puede ser una solución provisional para el problema principal de Emacs que se ralentiza al encontrar un archivo de este tipo.

nb Esta es una mejora sobre el código que publiqué inicialmente en esta respuesta, pero sigue siendo un trabajo en progreso. Las pruebas han sido mínimas. Los comentarios son bienvenidos.

También se aceptan sugerencias para otros (además css-mode) prog-modemodos principales no derivados para admitir por defecto.

Espero que encuentres que la diferencia se debe a font-lock. Cuando se va a realizar la fuente en el subconjunto del archivo que está visible en la ventana, se procede primero extendiendo la región de fuente de manera que incluya unidades semánticas completas. Vea el font-lock-extend-region-functionscódigo para esto. Es común que esto incluya extender la región para incluir líneas completas. Cuando las líneas son extremadamente largas, esto puede llevar a que la fuente se realice en una porción de contenido mucho más grande de lo que es realmente visible.

Además, cuando las nuevas líneas tienen información semántica, su ausencia a veces puede significar que los patrones regexp para el bloqueo de fuentes tienen que escanear más para determinar si coinciden o no.

Por lo general, desenrollo líneas largas y sangría por etiquetas (como HTML, XML, JSON).

Para hacer posible tal operación, agrego:

(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))

Me dividir la línea de expresiones regulares, para XML que: C-M-% >< RET >NL< RET !.

Después de que Emacs separe las líneas largas, es posible habilitar muchos *-modesy volver a sangrar el código.

Para la nota: ¿Cómo prevenir la desaceleración cuando un proceso inferior genera largas filas?

Creé mi propia solución para este problema aquí: https://github.com/rakete/too-long-lines-mode

No estaba satisfecho con la solución phils que cambia un búfer con líneas muy largas al modo fundamental, quería una solución que me permitiera mantener el resaltado de sintaxis y otras características del modo principal. Así que creé un modo menor que usa superposiciones para ocultar la mayoría de los caracteres de líneas demasiado largas.

Eso soluciona el problema y hace que emacs sea utilizable incluso en buffers con líneas muy largas, sin tener que volver al modo fundamental.

En mi configuración de Emacs tengo un modo con fuente personalizada, es decir, donde configuro font-lock-defaults. Una sola página hacia abajo usaría 30 segundos para mostrar parte de la línea de 30000 caracteres. Esta ralentización se solucionó reduciendo el retroceso regexp. En lugar de:

  (". * terminó con un comando incompleto *" 0 font-lock-comment-face)

hacer esto

  ("^. \ {1,80 \} terminó con un comando incompleto *" 0 font-lock-comment-face)

En mis búferes de modo shell (shell Mx), me encuentro con tuberías sed -r 's/(.{2000}).*/\1/' -upara evitar largas colas.

Utilizo la siguiente función para abrir dired-modearchivos grandes con líneas largas:

(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)

Aquí hay una solución, tomada de 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)))))