Comment empêcher les lignes extrêmement longues de ralentir Emacs?

Je vois des performances extrêmement variées en fonction du nombre de nouvelles lignes figurant dans le fichier que je visite.

Voici un exemple. J'ai deux fichiers 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

Ce sont deux fichiers JSON avec le même contenu. one_line.jsonest 18MiB de JSON sans nouvelles lignes. pretty_printed.jsona des nouvelles lignes et des espaces ajoutés, ce qui en fait 41 Mo.

Cependant, le fichier plus volumineux divisé sur plusieurs lignes est beaucoup plus rapide à ouvrir dans Emacs, aussi bien en mode Javascript qu'en mode fondamental.

Pourquoi Emacs a-t-il des performances si médiocres avec les longues lignes, vu que c'est en fait moins d'octets? Puis-je faire quelque chose pour améliorer les performances sans reformater les données en dehors d'Emacs?

Le traitement des longues lignes par Emacs n’est pas très optimisé. Pour un certain nombre d'opérations, Emacs doit balayer la ligne entière de manière répétée. Par exemple, pour afficher une ligne, Emacs doit déterminer la hauteur de la ligne, ce qui nécessite de balayer toute la ligne pour trouver le glyphe le plus haut. De plus, la recherche d’affichage bidirectionnel prend beaucoup de temps. Vous pouvez obtenir des informations supplémentaires dans, par exemple, la docstring de cache-long-line-scans(renommée cache-long-scansen 24.4).

Vous pouvez essayer de voir si régler bidi-paragraph-directionpour left-to-rightaméliorer votre vitesse [régler bidi-display-reorderingsur nil, fait plus ou moins la même chose mais est uniquement destiné à des fins internes / de débogage]. Cela supprime un contributeur important aux analyses de ligne, mais malheureusement pas le seul.

La meilleure option consiste à ajouter des nouvelles lignes. Vous pouvez diriger un fichier JSON, par exemple, python -c 'import json, sys ; json.dump(json.load(sys.stdin), sys.stdout, indent=2)'pour ajouter des nouvelles lignes et améliorer la lisibilité en général.

J'ai fait quelques brèves expériences avec cela en utilisant une copie réduite de jQuery. font-lock-modeet les flycheck-modedeux ont contribué à la lenteur, comme l'a fait js2-mode, et prettify-symbols-mode. line-number-modeet a column-number-modeeu un effet mineur. Une fois que j'avais désactivé tous les modes, la performance était relativement vive. Utilisez C-h met commencez à désactiver les différents modes activés ou essayez simplement de basculer vers fundamental-mode.

De manière intéressante, hexl-modeje pouvais parcourir le fichier sans problème, bien que les colonnes soient évidemment assez courtes. Malheureusement, les visual-line-modechoses ont vraiment ralenti.

Mon hypothèse est que la table de syntaxe est heureuse d’arrêter le traitement en fin de ligne et que, sur une seule ligne, elle doit tout réparer à chaque mise à jour.

J'ai téléchargé http://www.emacswiki.org/emacs/OverLongLineMode

Cette bibliothèque vous permet de définir des seuils simples de longueur de ligne au-delà desquels une variante de fundamental-modesera utilisée pour un fichier au lieu de son mode normal (pour les modes de programmation uniquement).

Il se peut que quelque chose dans ce sens puisse être ajouté à Emacs par défaut, mais il peut s'agir d'une solution provisoire au problème principal d'Emacs qui ralentit son analyse lorsqu'il rencontre un tel fichier.

nb Il s'agit d'une amélioration par rapport au code que j'ai initialement publié dans cette réponse, mais qui reste un travail en cours. Les tests ont été minimes. Les commentaires sont les bienvenus.

Les suggestions concernant d'autres modes principaux (en plus css-mode) non prog-modedérivés à prendre en charge par défaut sont également les bienvenues.

Je suppose que vous constaterez que la différence est due à font-lock. Lorsque la fontification doit être effectuée sur le sous-ensemble du fichier visible dans la fenêtre, elle commence par étendre la région de fontification de manière à inclure des unités sémantiques complètes. Voir le font-lock-extend-region-functionscode pour cela. Il est courant que cela inclue l'extension de la région pour inclure des lignes complètes. Lorsque les lignes sont extrêmement longues, la fontification peut être effectuée sur un bloc de contenu beaucoup plus volumineux que ce qui est réellement visible.

De plus, lorsque les nouvelles lignes contiennent elles-mêmes des informations sémantiques, leur absence peut parfois signifier que les modèles d'expressions rationnelles pour le verrouillage de police doivent analyser davantage afin de déterminer s'ils correspondent ou non.

Je déroule généralement de longues lignes et indente par balises (comme HTML, XML, JSON).

Afin de rendre cette opération possible, j'ajoute:

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

Je coupais ligne par regex, pour XML il: C-M-% >< RET >NL< RET !.

Après qu'Emacs ait divisé de longues lignes, il est possible d'activer de nombreux *-modescodes et des codes de réindentation.

Pour la note: Comment empêcher le ralentissement lorsqu'un processus inférieur génère de longues lignes?

J'ai créé ma propre solution à ce problème ici: https://github.com/rakete/too-long-lines-mode

Je n'étais pas satisfait de la solution phils qui bascule un tampon avec de très longues lignes en mode fondamental. Je recherchais une solution me permettant de conserver la coloration syntaxique et d'autres fonctionnalités en mode majeur. J'ai donc créé un mode mineur qui utilise des incrustations pour masquer la plupart des caractères de lignes trop longues.

Cela contourne le problème et rend emacs utilisable même dans les tampons avec de très longues lignes, sans avoir à revenir en mode fondamental.

Dans ma configuration Emacs, j'ai un mode avec une fontification personnalisée, c'est-à-dire où je le fixe font-lock-defaults. Une seule page vers le bas prendrait 30 secondes pour afficher une partie de la ligne 30000 caractères. Ce ralentissement a été corrigé en réduisant le retour arrière des expressions rationnelles. Au lieu de:

  (". * se termine par une commande incomplète *" 0 font-lock-comment-face)

fais ça

  ("^. \ {1,80 \} s'est terminé par une commande incomplète *" 0 font-lock-comment-face)

Dans mes mémoires tampons en mode shell (shell Mx), je me retrouve sed -r 's/(.{2000}).*/\1/' -uà contourner pour éviter les longues lignes.

J'utilise la fonction suivante pour ouvrir de dired-modegros fichiers avec de longues lignes:

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

Voici une solution de contournement, tirée d’ 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)))))