Vantaggi dell'impostazione delle variabili con setq anziché custom.el?

Vedo molte persone (autori di estensioni e altri) fornire esempi di configurazione con setq:

(setq foo 'bar)

Questi parametri sono spesso definiti con defcustom, rendendoli disponibili per la personalizzazione custom.el.

Di solito lo uso custom.elper impostarli. Ci sarebbe qualche vantaggio nell'usare setqinvece o i due metodi sono approssimativamente equivalenti?

Alcune persone potrebbero pensare che sia più semplice da usare setq. Alcune persone potrebbero pensare che sia più nitido. In realtà, è ingenuo nel caso generale.

È vero che per alcune opzioni utente non importa. Ma per altri è importante ed setqè l'approccio sbagliato per quelle opzioni. Quindi, come regola generale, setqè l'approccio sbagliato.

Se si utilizza custom-set-variableso customize-set-variableinvece di setq, o se si utilizza l'interfaccia utente personalizzata (ad es. M-x customize-option), Si è certi che qualsiasi codice di inizializzazione o aggiornamento previsto per il valore dell'opzione verrà automaticamente attivato ed eseguito secondo necessità. Se lo usi setq, questo non sarà fatto.

Ora, è anche vero che la maggior parte delle opzioni utente, in particolare molte delle quali scritte per le librerie terze parti, non fanno uso delle defcustomparole chiave :sete :initialize, e l'utilizzo setqnon ha importanza per loro. Ma molte opzioni Emacs alla vaniglia usano tali parole chiave e, per quelle che lo fanno, setqnon è la cosa giusta. Quindi, se si desidera utilizzare il codice Lisp e non l'interfaccia utente personalizzata per impostare le opzioni, è meglio usare custom-set-variableso customize-set-variableinvece di setq. Non fa mai male e talvolta aiuta (molto).

Ma ciò che consiglio è di fare entrambe queste cose:

• Utilizzare l'interfaccia utente personalizzata invece di scrivere il codice Lisp per questo.

• Definire la variabilecustom-file , in modo che Personalizza scriva le personalizzazioni nel file e non nel file init ( ~/.emacs). IOW, mantieni il tuo codice di inizializzazione scritto a mano separato dal codice automatico scritto da Personalizza.

Preferisco setqpiù customizeper diversi motivi:

1. Innanzitutto, consente di impostare programmaticamente le variabili (come in, (setq foo (calculate-foo))). Uso questo potere continuamente nella mia configurazione per mantenere le cose ASCIUTTE. Per me, il punto centrale dell'utilizzo di Emacs è la programmabilità e l' customizeinterfaccia non fa altro che ostacolare.
2. setqsi presta meglio al controllo della versione e all'organizzazione del codice. Ho diviso la mia inizializzazione tra dozzine di file; se tutto fosse in un unico enorme custom.elfile, sarebbe molto più difficile trovare e modificare rapidamente le impostazioni.
3. Questo è soggettivo, ma per me l'intera customizeinterfaccia sembra un'orribile reliquia delle peggiori interfacce utente degli anni '90. Preferirei modificare il testo con il potere di Emacs ogni giorno.

@Drew fa alcuni punti positivi su alcune sottigliezze con :sete :initialize. Uso Emacs da anni e raramente ho riscontrato problemi del genere. Quando lo faccio, è facile scambiare setqper custom-set-variablein casi specifici.

Un vantaggio dell'utilizzo setqanziché della customizeleggibilità. Uno è libero di annotare ogni personalizzazione a proprio piacimento quale IMO migliora la leggibilità. Si possono anche raggruppare le personalizzazioni correlate che migliorano la modularità. Infine, direi che navigare attraverso un buffer elisp è più "facile" che navigare nell'interfaccia utente e nei widget personalizzati.

D'altra parte, personalizzare consente di ripristinare facilmente i valori predefiniti che possono essere inestimabili quando le cose vanno in tilt.

EDIT: la risposta di Drew fornisce un ottimo motivo per utilizzare customize-set-variablesche può fornire tutti i vantaggi che ho sottolineato. Tuttavia, l'interfaccia utente personalizzata non si presta a configurazioni portatili tra piattaforme diverse con la stessa facilità di elisp raw. Se si richiede che una variabile abbia un'impostazione dipendente dal sistema operativo, in molti casi sarà necessario eseguire il fallback su elisp. Il mio punto sulla navigazione più semplice nei buffer elisp è ancora valido.

Un'altra alternativa è quella di utilizzare il pacchetto d' uso di John Wiegley . Questo fornisce un modo programmatico per configurare i pacchetti che funzionano bene con il processo di inizializzazione dei pacchetti di emacs 24+. Ecco un esempio di utilizzo dal readme:

(use-package color-moccur
  :commands (isearch-moccur isearch-all)
  :bind (("M-s O" . moccur)
         :map isearch-mode-map
         ("M-o" . isearch-moccur)
         ("M-O" . isearch-moccur-all))
  :custom (isearch-lazy-highlight t)
  :config (use-package moccur-edit))

Il punto è che use package è una macro e non valuta immediatamente i suoi argomenti. I parametri :inite :configvengono valutati in diverse fasi del processo di inizializzazione, rendendo possibile avere la configurazione di ciascun pacchetto in un posto, ma ogni parte deve essere eseguita nella fase appropriata di inizializzazione.

Senza qualcosa come use-packagealcuni pacchetti richiedono una parte del loro codice di inizializzazione prima (package-initialize)e un'altra parte da seguire. Se hai molti packegas del genere, le loro inizializzazioni dovrebbero essere intercalate.

Un altro vantaggio use-packageè che può installare automaticamente i pacchetti mancanti dall'uso di package.el se porti .emacs su un nuovo computer o se condividi la configurazione con un altro utente e tutta l'inizializzazione può essere rinviata fino a quando un pacchetto non deve essere effettivamente caricato.

Esistono inoltre argomenti per parole chiave aggiuntive che consentono un maggiore controllo sul processo di inizializzazione.

Detto questo, un grande vantaggio di personalizzare è che ti mostra cosa c'è da configurare in un determinato pacchetto. Questo è uno dei motivi per cui lo uso ancora per molti dei miei pacchetti.