Come posso evitare che le linee estremamente lunghe rallentino Emacs?

Vedo prestazioni estremamente varie a seconda di quante nuove righe ci sono nel file che sto visitando.

Ecco un esempio Ho due file 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

Questi sono due file JSON con lo stesso contenuto. one_line.jsonè 18 MiB di JSON senza alcuna nuova riga. pretty_printed.jsonha newline e spazi bianchi aggiunti, rendendolo 41 MiB.

Tuttavia, il file più grande suddiviso su molte linee è molto più veloce da aprire in Emacs, sia in modalità Javascript che in modalità Fondamentale.

Perché Emacs ha prestazioni così scarse con linee lunghe, dal momento che in realtà ha un minor numero di byte? Posso fare qualcosa per migliorare le prestazioni senza riformattare i dati al di fuori di Emacs?

La gestione delle lunghe file da parte di Emacs non è ottimizzata molto bene. Per una serie di operazioni, Emacs deve scansionare ripetutamente l'intera riga. Ad esempio, per visualizzare una linea, Emacs deve capire l'altezza della linea, che richiede la scansione dell'intera linea per trovare il glifo più alto. Inoltre, la scansione per la visualizzazione bidirezionale richiede molto tempo. È possibile ottenere alcune informazioni aggiuntive, ad esempio, nel docstring di cache-long-line-scans(rinominato cache-long-scansin 24.4).

Puoi provare a vedere se l'impostazione bidi-paragraph-directionper left-to-rightmigliorare la velocità per te [l'impostazione bidi-display-reorderingsu nil, fa più o meno la stessa cosa ma è pensata solo per scopi interni / di debug]. Questo rimuove un contributo significativo alle scansioni di linea, ma purtroppo non l'unico.

L'opzione migliore è aggiungere nuove righe. È possibile reindirizzare un file JSON ad esempio python -c 'import json, sys ; json.dump(json.load(sys.stdin), sys.stdout, indent=2)'per aggiungere nuove righe e migliorare la leggibilità in generale.

Ho fatto alcuni brevi esperimenti con questo usando una copia minimizzata di jquery. font-lock-modeed flycheck-modeentrambi hanno contribuito alla lentezza, come ha fatto js2-mode, e prettify-symbols-mode. line-number-modee ha column-number-modeavuto un effetto minore. Una volta avevo disattivato tutte le diverse modalità sebbene le prestazioni fossero relativamente scattanti. Usa C-h me inizia a disabilitare le diverse modalità abilitate, oppure prova a passare a fundamental-mode.

È interessante notare che usando hexl-modeho potuto volare attraverso il file senza problemi, anche se ovviamente le colonne erano piuttosto brevi. Purtroppo ha visual-line-modedavvero rallentato le cose.

La mia ipotesi è che la tabella di sintassi sia felice di interrompere l'elaborazione alle terminazioni di riga e quando è tutto su una riga deve replicare tutto su ogni aggiornamento.

Ho caricato http://www.emacswiki.org/emacs/OverLongLineMode

Questa libreria consente di impostare soglie di lunghezza della linea oltre le quali fundamental-modeverrà utilizzata una variante di un file anziché la sua modalità normale (solo per le modalità di programmazione).

Potenzialmente, qualcosa del genere potrebbe essere aggiunto a Emacs per impostazione predefinita, ma questa può essere una soluzione temporanea per il problema principale di Emacs che rallenta a una scansione quando si incontra un file del genere.

nb Si tratta di un miglioramento rispetto al codice inizialmente pubblicato in questa risposta, ma ancora in fase di elaborazione. I test sono stati minimi. I commenti sono benvenuti.

Sono anche ben accetti i suggerimenti per altre modalità principali ( css-modenon specializzate) non prog-modesupportate da supportare di default.

Immagino che scoprirai che la differenza è dovuta font-lock. Quando la fontificazione deve essere eseguita sul sottoinsieme del file che è visibile nella finestra, procede estendendo prima la regione di fontificazione in modo tale da includere unità semantiche complete. Vedi il font-lock-extend-region-functionscodice per questo. È comune per questo includere l'estensione della regione per includere le linee complete. Quando le linee sono estremamente lunghe, ciò può portare alla fontificazione che viene eseguita su una porzione di contenuto molto più ampia di quanto sia effettivamente visibile.

Inoltre, quando le newline stesse hanno informazioni semantiche, la loro assenza a volte può significare che i pattern regexp per il blocco dei caratteri devono eseguire ulteriori scansioni per determinare se corrispondono o meno.

Solitamente srotolo lunghe righe e rientro per tag (come HTML, XML, JSON).

Per rendere possibile tale operazione, aggiungo:

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

Ho diviso riga per regex, per XML esso: C-M-% >< RET >NL< RET !.

Dopo che Emacs ha diviso le righe lunghe, è possibile abilitare molti *-modese rientrare il codice.

Per la nota: come prevenire il rallentamento quando un processo inferiore genera linee lunghe?

Ho creato la mia soluzione per questo problema qui: https://github.com/rakete/too-long-lines-mode

Non ero soddisfatto della soluzione phils che commuta un buffer con linee molto lunghe in modalità fondamentale, volevo una soluzione che mi permettesse di mantenere l'evidenziazione della sintassi e altre funzionalità della modalità principale. Così ho creato una modalità minore che utilizza le sovrapposizioni per nascondere la maggior parte dei personaggi con linee troppo lunghe.

Ciò risolve il problema e rende emacs utilizzabili anche in buffer con linee molto lunghe, senza dover ricorrere alla modalità fondamentale.

Nella mia configurazione di Emacs ho una modalità con fontificazione personalizzata, ovvero dove ho impostato font-lock-defaults. Una sola pagina in basso impiegherebbe 30 secondi per visualizzare parte di una riga di 30000 caratteri. Questo rallentamento è stato risolto riducendo il backtracking di regexp. Invece di:

  (". * è terminato con un comando incompleto *" 0 font-lock-comment-face)

Fai questo

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

Nei miei buffer in modalità shell (shell Mx), mi ritrovo a sed -r 's/(.{2000}).*/\1/' -ueseguire il piping per evitare le lunghe file.

Uso la seguente funzione per aprire dired-modefile di grandi dimensioni con linee lunghe:

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

Ecco una soluzione alternativa, presa da 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)))))