Переваги налаштування змінних за допомогою setq замість custom.el?

Я бачу, що багато людей (автори розширень та інші) наводять приклади конфігурації з setq:

(setq foo 'bar)

Ці параметри часто визначається з defcustom, що робить їх доступними для настройки через custom.el.

Я зазвичай використовую їх custom.elдля встановлення. Чи є якась перевага використання setqзамість цього або два способи приблизно еквівалентні?

Деякі люди можуть подумати, що це простіше у використанні setq. Деякі люди можуть подумати, що це більш пихато. Насправді в загальному випадку це наївно.

Це правда, що для деяких параметрів користувача це не має значення. Але для інших це має значення, і setqце неправильний підхід для цих варіантів. Отже, як правило, setqнеправильний підхід.

Якщо ви використовуєте custom-set-variablesабо customize-set-variableзамість цього setq, або використовуєте користувальницький інтерфейс користувача (наприклад M-x customize-option), ви впевнені, що будь-яка передбачувана ініціалізація або оновлення коду, необхідна для значення параметра, буде автоматично запущена і запуститься за потребою. Якщо ви користуєтеся setq, цього не буде зроблено.

Тепер також трапляється так, що більшість параметрів користувачів, особливо багато з них, написаних для сторонніх бібліотек, не використовують defcustomключові слова :setта :initialize, а використання setqдля них не має значення. Але багато варіантів ванільного Emacs використовують такі ключові слова, і для тих, хто це робить, setqце не правильна річ. Тож якщо ви хочете використовувати параметр Lisp, а не Індивідуальний інтерфейс для встановлення своїх параметрів, тоді вам краще скористатися custom-set-variablesабо customize-set-variableзамість цього setq. Це ніколи не болить, а іноді допомагає (багато).

Але я рекомендую робити обидві дії:

• Використовуйте користувальницький інтерфейс замість написання коду Lisp для цього.

• Визначте зміннуcustom-file , щоб Налаштувати записувати налаштування у цей файл, а не у ваш файл init ( ~/.emacs). IOW, тримайте рукописний код ініціалізації окремо від автоматичного коду, написаного у налаштуваннях.

Я віддаю перевагу setqнад customizeкількома причинами:

1. Перш за все, він дозволяє програмно встановлювати змінні (як у, (setq foo (calculate-foo))). Я використовую цю силу весь час у моїй конфігурації, щоб зберегти речі СУХІ. Для мене вся суть використання Emacs - це програмованість, і customizeінтерфейс не робить нічого, окрім як заважати.
2. setqкраще піддається контролю версій та організації коду. Я розділив ініціалізацію між десятками файлів; якби все було в одному величезному custom.elфайлі, було б набагато важче швидко знайти та відредагувати налаштування.
3. Це суб'єктивно, але для мене весь customizeінтерфейс відчуває себе жахливою реліквією з найгірших інтерфейсів 90-х. Я вважаю за краще будь-який день редагувати текст потужністю Emacs.

@Drew робить деякі хороші моменти щодо деяких тонкощів з :setі :initialize. Я використовую Emacs роками і рідко стикався з подібними проблемами. Коли я це роблю, це легко замінити setqна custom-set-variableконкретні випадки.

Одна з переваг використання setqзамість customize- читабельність. Кожен може коментувати кожне налаштування на свій смак, що IMO покращує читабельність. Можна також згрупувати пов'язані налаштування разом, що покращує модульність. Нарешті, я заперечую, що навігація по буферу elisp є більш "легкою", ніж навігація, налаштувати інтерфейс користувача та віджети.

З іншого боку, налаштування дозволяє вам легко повернутися до значень за замовчуванням, які можуть бути безцінними, коли речі йдуть без проблем.

EDIT: Відповідь Дрю є чудовим приводом для використання, customize-set-variablesякий може забезпечити всі переваги, які я зазначив. Однак користувальницький інтерфейс користувача не піддається портативних конфігурацій між різними платформами так легко, як це робить сировина elisp. Якщо вам потрібна змінна, щоб встановити залежність від ос, вам доведеться в багатьох випадках відновлюватись до elisp. Моя думка про полегшену навігацію в буферах elisp все ще стоїть.

Іншою альтернативою є використання Джона Wiegley в споживчу упаковку . Це надає програмний спосіб налаштування пакетів, які чудово розігруються з процесом ініціалізації пакетів emacs 24+. Ось приклад використання з 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))

Справа в тому, що використання пакету є макросом і не оцінює його аргументи відразу. Параметри :initта :configпараметри оцінюються на різних етапах процесу ініціалізації, що дозволяє конфігурацію кожного пакету в одному місці, але кожну частину виконувати на відповідному етапі ініціалізації.

Без що - щось на зразок use-packageдеяких пакетів вимагає частині їх коди ініціалізації, перш ніж (package-initialize)інша частина , щоб піти після. Якщо у вас є багато подібних пакетів, тоді їх ініціалізації потрібно було б переплутати.

Ще одна перевага use-packageполягає в тому, що він може автоматично встановлювати відсутні пакети з використання пакета.el, якщо ви переносите .emacs на нову машину або якщо ви ділитесь своєю конфігурацією з іншим користувачем, і вся ініціалізація може бути відкладена, поки пакет фактично не потребує завантаження.

Існують також додаткові аргументи ключових слів, які дозволяють більше контролювати процес ініціалізації.

Все, що сказано, одна велика перевага налаштування - це те, що воно показує вам, що потрібно налаштувати в будь-якому даному пакеті. Це одна з причин, що я все ще використовую його для багатьох своїх пакунків.