Преимущества установки переменных с помощью 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, а не пользовательский интерфейс Customize для настройки своих параметров, тогда вам лучше использовать custom-set-variablesили customize-set-variableвместо setq. Это никогда не ранит, а иногда помогает (очень).

Но я рекомендую сделать обе эти вещи:

• Используйте пользовательский интерфейс Customize вместо написания кода для этого.

• Определите переменнуюcustom-file , чтобы Customize записывал настройки в этот файл, а не в файл инициализации ( ~/.emacs). IOW, держите свой рукописный код инициализации отдельно от автоматического кода, написанного Customize.

Я предпочитаю 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 более «проста», чем навигация по настройке пользовательского интерфейса и виджетов.

С другой стороны, настройка позволяет вам легко вернуться к значениям по умолчанию, которые могут быть бесценными, когда дела идут плохо.

РЕДАКТИРОВАТЬ: Ответ Дрю предоставляет отличную причину для использования, customize-set-variablesкоторая может обеспечить все преимущества, которые я указал Тем не менее, пользовательский интерфейс Customize не поддается переносимым конфигурациям на разных платформах, как это делает raw 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))

Дело в том, что use package является макросом и не оценивает свои аргументы сразу. Параметры :initи :configоцениваются на разных этапах процесса инициализации, что позволяет иметь конфигурацию каждого пакета в одном месте, но каждая часть выполняется на соответствующем этапе инициализации.

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

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

Существуют также дополнительные ключевые аргументы, которые позволяют лучше контролировать процесс инициализации.

Все это говорит о том, что одним из больших преимуществ настройки является то, что она показывает, что нужно настраивать в любом конкретном пакете. Это одна из причин, почему я до сих пор использую его для многих своих пакетов.