Keuntungan mengatur variabel dengan setq daripada custom.el?

Saya melihat banyak orang (penulis ekstensi dan lainnya) memberikan contoh konfigurasi dengan setq:

(setq foo 'bar)

Parameter ini sering ditentukan dengan defcustom, sehingga tersedia untuk kustomisasi custom.el.

Saya biasanya menggunakan custom.eluntuk mengaturnya. Apakah akan ada keuntungan menggunakan setqsebaliknya atau apakah kedua metode ini hampir setara?

Beberapa orang mungkin berpikir itu lebih mudah digunakan setq. Beberapa orang mungkin berpikir itu lebih lispy. Pada kenyataannya, itu naif dalam kasus umum.

Memang benar bahwa untuk beberapa opsi pengguna tidak masalah. Tetapi bagi yang lain, itu penting, dan setqmerupakan pendekatan yang salah untuk opsi-opsi itu. Jadi sebagai aturan umum, setqadalah pendekatan yang salah.

Jika Anda menggunakan custom-set-variablesatau customize-set-variablealih-alih setq, atau jika Anda menggunakan antarmuka pengguna Kustomisasi (mis. M-x customize-option), Maka Anda yakin bahwa setiap inisialisasi atau memperbarui kode yang diperlukan untuk nilai opsi akan secara otomatis dipicu dan dijalankan sesuai kebutuhan. Jika Anda menggunakan setq, ini tidak akan dilakukan.

Sekarang, ini juga merupakan kasus dimana sebagian besar opsi pengguna, terutama banyak dari mereka yang ditulis untuk perpustakaan pihak ke-3, tidak menggunakan defcustomkata kunci :setdan :initialize, dan menggunakan setqtidak penting bagi mereka. Tetapi banyak opsi vanilla Emacs menggunakan kata kunci seperti itu, dan bagi mereka yang melakukannya, setqbukanlah hal yang benar. Jadi jika Anda ingin menggunakan kode Lisp dan bukan Customize UI untuk mengatur opsi Anda, maka Anda lebih baik menggunakan custom-set-variablesatau customize-set-variablebukannya setq. Tidak pernah sakit dan kadang-kadang membantu (banyak).

Tetapi yang saya rekomendasikan adalah melakukan kedua hal ini:

• Gunakan Customize UI alih-alih menulis kode Lisp untuk ini.

• Tentukan variabelcustom-file , sehingga Kustomisasi menulis kustomisasi ke file itu dan bukan ke file init Anda ( ~/.emacs). TKI, biarkan kode inisialisasi tulisan tangan Anda terpisah dari kode otomatis yang ditulis oleh Customize.

Saya lebih suka setqlebih customizekarena beberapa alasan:

1. Pertama dan terpenting, ini memungkinkan variabel untuk diatur secara programatik (seperti dalam, (setq foo (calculate-foo))). Saya menggunakan kekuatan ini sepanjang waktu dalam konfigurasi saya untuk menjaga hal-hal KERING. Bagi saya, inti dari menggunakan Emacs adalah kemampuan diprogram, dan customizeantarmuka tidak melakukan apa pun selain menghalangi.
2. setqcocok untuk kontrol versi dan organisasi kode. Saya membagi inisialisasi saya di antara puluhan file; jika semuanya ada dalam satu custom.elfile besar , akan jauh lebih sulit untuk menemukan dan mengedit pengaturan dengan cepat.
3. Ini subjektif, tetapi bagi saya seluruh customizeantarmuka terasa seperti peninggalan mengerikan dari UI terburuk tahun 90-an. Saya lebih suka mengedit teks dengan kekuatan Emacs setiap hari.

@Rew membuat beberapa poin bagus tentang beberapa seluk-beluk dengan :setdan :initialize. Saya telah menggunakan Emacs selama bertahun-tahun dan jarang mengalami masalah seperti itu. Ketika saya lakukan, itu mudah untuk swap keluar setquntuk custom-set-variabledalam kasus-kasus tertentu.

Salah satu keuntungan menggunakan setqalih-alih customizeadalah keterbacaan. Satu bebas untuk membubuhi keterangan setiap penyesuaian sesuai keinginan seseorang yang IMO meningkatkan keterbacaan. Satu juga dapat mengelompokkan penyesuaian terkait bersama yang meningkatkan modularitas. Akhirnya, saya berpendapat bahwa menavigasi melalui buffer elisp lebih "mudah" daripada menavigasi UI dan widget khusus.

Di sisi lain, kustomisasi memungkinkan Anda dengan mudah kembali ke nilai default yang tidak ternilai harganya ketika berbagai hal menjadi berantakan.

EDIT: Jawaban Drew memberikan alasan bagus untuk menggunakan customize-set-variablesyang dapat memberikan semua keuntungan yang saya tunjukkan. Namun, Customize UI tidak cocok untuk konfigurasi portabel di antara platform yang berbeda semudah yang dilakukan oleh raw elisp. Jika Anda memerlukan variabel untuk memiliki pengaturan tergantung os, Anda harus mundur ke elisp dalam banyak kasus. Maksud saya tentang navigasi yang lebih mudah di buffer elisp masih berdiri.

Alternatif lain adalah dengan menggunakan John Wiegley ini penggunaan-paket . Ini menyediakan cara terprogram untuk mengonfigurasi paket yang berfungsi baik dengan proses inisialisasi paket emacs 24+. Berikut adalah contoh penggunaan dari 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))

Intinya adalah bahwa paket penggunaan adalah makro dan tidak mengevaluasi argumennya segera. The :initdan :configparameter yang dievaluasi pada berbagai tahap proses inisialisasi, sehingga memungkinkan untuk memiliki konfigurasi masing-masing paket di satu tempat, tetapi memiliki setiap bagian mengeksekusi pada tahap yang sesuai inisialisasi.

Tanpa sesuatu seperti use-packagebeberapa paket memerlukan bagian dari kode inisialisasi mereka untuk pergi sebelum (package-initialize)dan bagian lain untuk mengejar. Jika Anda memiliki banyak paket seperti itu maka inisialisasi mereka harus disisipkan.

Manfaat lain use-packageadalah bahwa ia dapat secara otomatis menginstal paket yang hilang dari menggunakan package.el jika Anda membawa Anda .emacs ke mesin baru atau jika Anda berbagi konfigurasi Anda dengan pengguna lain dan semua inisialisasi dapat ditunda sampai paket benar-benar perlu dimuat.

Ada juga argumen kata kunci tambahan yang memungkinkan kontrol lebih besar atas proses inisialisasi.

Semua yang dikatakan, satu keuntungan besar dari menyesuaikan adalah menunjukkan kepada Anda apa yang harus dikonfigurasi dalam paket yang diberikan. Itulah salah satu alasan saya masih menggunakannya untuk banyak paket saya.