custom.el 대신 setq를 사용하여 변수를 설정하면 이점이 있습니까?

많은 사람들 (확장자 및 기타 사람들)이 다음과 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그들에게 중요하지 않습니다. 그러나 많은 바닐라 이맥스 옵션은 그러한 키워드를 사용하며, setq그렇지 않은 키워드에는 적합하지 않습니다. 따라서 UI를 사용자 정의하지 않고 Lisp 코드를 사용하여 옵션을 설정하려는 경우 custom-set-variables또는 customize-set-variable대신에 사용하는 것이 좋습니다 setq. 그것은 결코 아프지 않으며 때로는 도움이됩니다 (많이).

그러나 내가 권장하는 것은 다음 두 가지를 모두 수행하는 것입니다.

• 이를 위해 Lisp 코드를 작성하는 대신 UI 사용자 정의를 사용하십시오 .

• custom-fileCustomize가 init 파일 ( ~/.emacs)이 아닌 해당 파일에 사용자 정의를 작성하도록 variable을 정의하십시오 . IOW, 손으로 작성한 초기화 코드를 Customize가 작성한 자동 코드와 별도로 유지하십시오.

내가 선호하는 setq동안 customize몇 가지 이유 :

1. 무엇보다 변수를 프로그래밍 방식으로 설정할 수 있습니다 (에서와 같이 (setq foo (calculate-foo))). 구성에서 항상이 기능을 사용하여 작업을 건조 상태로 유지합니다. 저에게는 Emacs를 사용하는 요점은 프로그래밍 가능성이며 customize인터페이스는 방해가되지 않습니다.
2. setq버전 관리 및 코드 구성에 더 적합합니다. 초기화를 수십 개의 파일로 분할했습니다. 모든 것이 하나의 거대한 custom.el파일에 있으면 설정을 빠르게 찾고 편집하기가 훨씬 더 어려워집니다.
3. 이것은 주관적이지만 나에게 전체 customize인터페이스는 90 년대 최악의 UI에서 끔찍한 유물처럼 느껴집니다. 나는 언제든지 Emacs의 힘으로 텍스트를 편집하고 싶습니다.

@Drew는와의 미묘함에 대해 좋은 점 :set을 제시 :initialize합니다. 나는 몇 년 동안 Emacs를 사용해 왔으며 그와 같은 문제는 거의 발생하지 않았습니다. 내가 할 때 특정 경우에 쉽게 교체 할 setq수 custom-set-variable있습니다.

setq대신 에 사용 하는 한 가지 장점 customize은 가독성입니다. IMO는 가독성을 향상시키기 위해 원하는대로 각 사용자 정의에 주석을 달 수 있습니다. 모듈화를 향상시키는 관련 사용자 정의를 함께 그룹화 할 수도 있습니다. 마지막으로, elisp 버퍼를 탐색하는 것이 UI 및 위젯 사용자 정의를 탐색하는 것보다 "쉬운"것이라고 주장합니다.

반면, customize를 사용하면 사물이 사라질 때 귀중한 기본값으로 쉽게 되돌릴 수 있습니다.

편집 : Drew의 대답은 customize-set-variables내가 지적한 모든 이점을 제공 할 수 있는 훌륭한 이유를 제공합니다. 그러나 Customize UI는 raw elisp만큼 쉽게 다른 플랫폼 간의 이식 가능한 구성에 적합하지 않습니다. 운영 체제에 따라 달라지는 변수가 필요한 경우 대부분의 경우 생략하기 위해 대체해야합니다. elisp 버퍼에서 더 쉬운 탐색에 대한 요점은 여전히 ​​유효합니다.

다른 대안은 John Wiegley의 use-package를 사용하는 것 입니다. 이는 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)하고 다른 일부는 계속해야합니다. 당신이 그런 packegas를 많이 가지고 있다면, 그들의 초기화는 인터리브되어야합니다.

또 다른 이점은 use-package.emacs를 새 컴퓨터로 가져 가거나 다른 사용자와 구성을 공유하고 패키지를 실제로로드해야 할 때까지 모든 초기화를 연기 할 수있는 경우 package.el을 사용하여 누락 된 패키지를 자동으로 설치할 수 있다는 것입니다.

초기화 프로세스를보다 강력하게 제어 할 수있는 추가 키워드 인수도 있습니다.

그러나 사용자 정의의 한 가지 큰 장점은 주어진 패키지에서 구성해야 할 것을 보여줍니다. 그것이 여전히 많은 패키지에 사용하는 이유입니다.