Organizzare il contenuto di ~ / .emacs.d / init.el e ~ / emacs.d?

1. Quando aggiungiamo sempre più righe ~/.emacs.d/init.elper vari scopi (per la modalità python, per emacs-eclim, per ...), il file diventa lungo e meno leggibile. C'è un modo per organizzare il suo contenuto?

2. La mia corrente ~/.emacs.dè simile a questa

   $ ls *
   init.el
   
   auto-save-list:
   
   elisp:
   python-mode.el-6.1.3
   
   elpa:
   archives        auctex-readme.txt         s-20140910.334
   auctex-11.87.7  emacs-eclim-20140809.207
   
   eshell:
   history
   

   python-mode.el-6.1.3è stato installato manualmente, mentre è emacs-eclim-20140809.207stato installato da elpa, e non sono sicuro al 100% che le altre cose sotto lo elpa/fossero elpa. Come posso organizzare il contenuto di ~/.emacs.d/?

Le persone che usano editor minori preferiscono suddividere il proprio codice in più file. Se stai usando Emacs, non c'è motivo di farlo: basta usare un singolo file di grandi dimensioni, che si divide in sezioni.

Ogni sezione dovrebbe iniziare con

^L
;;; title of the section

dove inserisci il ^Lcarattere digitando C-q C-l. È quindi possibile utilizzare comandi come C-x ]( forward-page) o C-x n p( narrow-to-page) per navigare nel file. Vedere la Sezione 25.4 (Pagine) del manuale di Emacs per ulteriori informazioni.

Un modo classico per farlo è dividere i .emacsfile in file separati. Ad esempio, puoi spostare tutti i tuoi contenuti web ~/.emacs.d/web-config.ele poi caricarli all'interno init.el:

(load "~/.emacs.d/web-config.el")

Se vuoi mantenerti ~/.emacs.dun po 'più organizzato, puoi anche spostare questi file di configurazione nella loro directory:

(load "~/.emacs.d/config/web.el")

Ora puoi semplicemente passare al file appropriato quando apporti modifiche alla tua configurazione.

Una cosa che manca a ciò sono le variabili impostate tramite il sistema di personalizzazione. Questi saranno ancora tutti nel tuo init.el. principale Apparentemente, c'è una piccola utility chiamata init split che ti permette di fare regole su quale impostazione di personalizzazione va dove, ma non l'ho mai usato da solo. In alternativa, il sistema "personalizza" può essere configurato per utilizzare un file separato per le sue modifiche alle impostazioni. Impostare la custom-filevariabile per specificare da dove leggere e scrivere le impostazioni di "personalizzazione" .

Per quanto riguarda la directory stessa, sono sempre stato contento del layout predefinito. La principale modifica che ho apportato è stata la creazione di una directory per tutti i miei pacchetti e librerie personalizzati non gestiti da package.el. Questo dà una sola casa al mio elisp personalizzato che non è correlato alla configurazione.

Se ti piace la modalità Org, puoi usarla per organizzare la tua .emacssenza dividerla. Nella mia configurazione attuale il mio .emacsfile avvia semplicemente un file init.org che ho sotto~/.emacs.d/init/init.org

(require 'org)

;; Load the actual configuration file
(org-babel-load-file
  (expand-file-name (concat user-emacs-directory "init/init.org")))

Usando file diversi devi grepinvece C-scercare semplicemente qualcosa e così via. Inoltre, è più semplice aggiungere diversi livelli alla tua organizzazione.

Basta spostare pezzi di codice init.elin file separati (librerie), che poi require. (Usa providenelle librerie per essere required.) Metti quei file dove vuoi e aggiorna di load-pathconseguenza.

Uso il suggerimento di Targzeta trovato nella directory di Emacs Wiki: Load .

Fondamentalmente ho un ~ / .emacs.d / load-directory.el:

;;;; ~/.emacs.d/load-directory.el

;; Handy function to load recursively all '.el' files in a given directory
(defun load-directory (directory)
  "Load recursively all '.el' files in DIRECTORY."
  (dolist (element (directory-files-and-attributes directory nil nil nil))
    (let* ((path (car element))
           (fullpath (concat directory "/" path))
           (isdir (car (cdr element)))
           (ignore-dir (or (string= path ".") (string= path ".."))))
      (cond
       ((and (eq isdir t) (not ignore-dir))
        (load-directory fullpath))
       ((and (eq isdir nil) (string= (substring path -3) ".el"))
        (load (file-name-sans-extension fullpath)))))))

Quindi ho appena inserito file separati nel mio ~ / .emacs.d / config:

~/.emacs.d/config ls
01-packages.el  02-style.el  03-modes.el  04-keybindings.el  05-functions.el

E finalmente ho questo nel mio ~ / .emacs.d / init.el:

;; Load all ".el" files under ~/.emacs.d/config directory.
(load "~/.emacs.d/load-directory")
(load-directory "~/.emacs.d/config")

Esiste ovviamente più di un modo per scuoiare questo particolare gatto. Il mio preferito preferito è usare outline-minor-modecon outshine . Estratto:

;; * This here is my emacs init file
;; ** Many subsections with headlines like this one omitted
;; ** Customising modes
;; […] more lines omitted
;; *** Org and outline modes
(autoload 'outshine-hook-function "outshine")
(add-hook 'outline-minor-mode-hook 'outshine-hook-function)
;; […] and more
;; * Emacs Magic
;;; Local Variables:
;;; mode: emacs-lisp
;;; coding: utf-8
;;; mode: outline-minor
;;; fill-column: 79
;;; End:

Si noti che sarà necessario ottenere il massimo dal proprio repository di pacchetti preferito.

Uso la seguente struttura per tenere traccia di pacchetti e file

~/.emacs.d
|-- elpa            ;; Package.el packages
|-- hack            ;; Development versions of packages (e.g. org, personal packages)
|-- single-lisp     ;; Individual lisp files from outside sources (e.g. EmacsWiki)
|-- site-lisp       ;; Lisp packages not managed by package.el (directories)
|-- user-config     ;; Machine/situation specific customization (work vs home)
|   `-- custom.el   ;; Customization settings
|-- lisp            ;; Individual .el files to keep init.el clean
|   `-- defaults.el ;; Default configuration settings
`-- init.el

Quindi utilizzo use-packageper gestire quali pacchetti vengono caricati e quali personalizzazioni vengono impostate per ciascun pacchetto. Il più delle volte solo hacke elparichiedono un aggiornamento, le altre cartelle sono spesso per pacchetti una tantum che voglio testare o usare brevemente ma non è necessario caricare (anche al minimo).

custom.el è per le impostazioni personalizzate, che preferisco non usare (e non versione anche se lo uso).

defaults.elè per la configurazione generale (barra dei menu, font, codifica, ecc.) che può quindi essere sovrascritta in qualsiasi file .el user-config/per consentire un sistema che funzionerà come mi aspetto, ma che può essere adattato all'ambiente.

Avevo cercato in precedenza di tenere functions, macros, advicein pacchetti separati per consentire la delimitazione tra contenuto, ma ha incontrato definizione / richiedere questioni così hanno messo di nuovo in quelle init.el. Alla fine potrebbero essere rimessi ~/.emacs.d/lisp/.

Cerco di mantenere init.elordinato, ordinare i contenuti in base alla funzione e allo scopo in modo che ritrovarli sia semplice. Ho avuto il init.elfile monolitico e ho continuato ad aggiungere nuovi contenuti alla fine (o dove pensavo potesse adattarsi) e poi avrei finito per non sapere cosa avevo aggiunto o dove l'avevo aggiunto quando sono andato a cercarlo (e a volte la ricerca usando isearchnon mi ha aiutato poiché non riuscivo a ricordare come ho chiamato le cose in quel momento).

Tutte le risposte esistenti riguardano le migliori pratiche per l'organizzazione di file creati manualmente , come init.ele amici. Altrettanto importante è l'organizzazione di tutti i file creati automaticamente da vari pacchetti, e per questo il pacchetto no-litteringè eccellente.

Ho aggiunto

  (when (string= (buffer-name) "init.el")
    (setq imenu-generic-expression
      '((nil "^;; \\[ \\(.*\\)" 1))))

a emacs-lisp-mode-hook. Quindi aggiungi alle sezioni del file "yasnippet", "packaging", "java mode", ecc. Funziona bene con le mie 1000 righe di codice (commenti inclusi).

EDIT: Finalmente passo da una sezione all'altra con helm-imenu. In realtà il timone si aggancia automaticamente alla normale funzione imenu quindi tutto ciò di cui ho bisogno è

       (local-set-key (kbd "C-*") 'imenu)

Ho diviso il mio .emacsfile relativamente piccolo in tre parti:

• emacs-custom.el per le personalizzazioni, strappando molti dati ingombranti e inutili; il file viene automaticamente riscritto senza toccare il file .emacs principale , impedendo modifiche spurie.

  (setq custom-file "~/.emacs-custom.el")
  (load custom-file)
  

• lg-lib.el per il codice piuttosto che per la configurazione: caricamento delle mie librerie da posizioni di origine non standard anziché dalla directory dei pacchetti e definizione di varie funzioni (per lo più copiate e hackerate in assenza di un pacchetto adeguato); è un'altra grande riduzione del conteggio delle righe .emacs .

  (load "~/lg-lib")
  

• Il file .emacs principale : senza codice ingombrante e variabili di personalizzazione ingombranti, contiene requirechiamate per pacchetti, variabili che non fanno parte del sistema Personalizza e chiamate di funzioni assortite per caricare e inizializzare i pacchetti. Lo "organizzo" tenendo attentamente insieme tutte le linee relative allo stesso pacchetto o funzionalità e separando ulteriormente il caricamento del pacchetto e le impostazioni relative al pacchetto dalla funzionalità "core". Un estratto abbastanza rappresentativo:

  (require 'ido)
  (ido-mode t)
  
  (require 'auto-complete)
  (add-to-list 'ac-dictionary-directories "~/.emacs.d/ac-dict")
  
  (require 'auto-complete-config)
  (ac-config-default)
  (global-auto-complete-mode t)
  

  Queste sezioni sono minuscole, ma rimarrebbero gestibili con molte più linee di configurazione per ciascun pacchetto.

Seguire la configurazione di un master Emacs, ad esempio https://github.com/purcell/emacs.d

Ad esempio, per quanto riguarda come organizzare pacchetti installati manualmente e pacchetti installati da ELPA, l'installazione di Steven Purcell ha

a place for 3rd party code which isn't available in MELPA or other
package repositories. This directory and its immediate
subdirectories will be added to load-path at start-up time.

Notably, in Emacs 23.x, a backported package.el is automatically
downloaded and installed here

Perché seguire un maestro? Un punto importante del mio "Master emacs in un anno" è che i neofiti possono così evitare in modo efficiente i costi generali di installazione e "gotchas".

Capisco che molte persone non sono d'accordo con me, ma ecco il mio caso (dettagliato nel mio articolo ):

Ho iniziato ad usare Emacs usando la rispettata configurazione di Purcell ( 1403 stelle GitHub a partire da novembre 2014!), Stabile (5 anni di sviluppo). Nonostante ciò, ho ancora avuto molti problemi . Steve Purcell mi ha aiutato a risolvere tutti questi problemi. (In realtà sono diventato il suo Padawan per oltre un anno.) Usando la sua configurazione e usando i problemi del suo repository per segnalare problemi, e sfruttando la sua esperienza, ho evitato di perdere molto tempo. Ancora oggi osservo ancora molte persone che usano git submoduleper gestire i plugin di terze parti. Sia Steve ed io rinunciato utilizzando git submoduleper questo , perché può essere un tale valle di lacrime .

Ma se sei molto fiducioso delle tue capacità o preferisci di gran lunga l'autoapprendimento, questo non è il percorso che fa per te.

Un modo innovativo e semplice per ripulire la tua .emacs.dcartella è usare org-modee delineare tutto usando i blocchi sorgente. Quindi, nel tuo .emacsfile, punta a config.org.

Una risorsa meravigliosa su questo è Harry Schwartz. Ha un video di YouTube che tocca e un post sul blog che spiega i dettagli . Sono stato in grado di seguirlo come un emacs noob e ottenere tutto il setup. Funziona come un fascino. 1 file per il mio intero init.