ㅈㅅㄹ

발 (풋 페달) 키보드 제작기

DOoMSDaY — Wed, 26 Jul 2017 23:34:42 +0900

이건 RSI에 대항하는 몸부림 중 하나이다. 최근들어 왼쪽 인대 부근이나 새끼 손가락 쪽 손등이, 한참 회사에서 일 하다 퇴근할 때 쯤 저릿저릿한게 심상치 않다. 이 바닥 생활을 오래 해서 그런 지 아니면 진짜 이맥스 때문인지... 어쨌건 혹사 당하는 왼쪽 새끼 손가락 말고 다른 좀 멀쩡한 곳으로 돌려막기를 하긴 해야 겠다는 생각이 들어, 결국 구전되어 오는 이맥스 유저들의 필살기인 풋 페달에 도전해 보기로 했다.

그러나 풋 페달이 아무리 필살기라 하더라도 아무나 그 필살기를 쓸 수 있는 것은 아니기에, (써 보다 적응 못했다는 경험기를 레딧에서 충분히 읽을 수 있다) 일단 내가 풋 페달에 적응이 가능한 지부터 테스트 하기로 했다. 아무래도 원래 지를려고 했던, 위 사진에 보이는 Kinesis foot pedal 자체가 하는 일 대비해선 가격이 너무 쎄기 때문에 지금까지 선뜻 풋 페달을 시도하지 못했기도 하니까. 그래서 일단은 집에 굴러다니는 아두이노와 발판 스위치의 조합으로 프로토타이핑을 해 보았다.

펌 웨어는 HID library 써서 대충 짰다. 어차피 키 세개짜리라 뭐 간단하게 간단하게.

/*
 * Foot pedal prototype
 */

#include <HID.h>
#include <Keyboard.h>

#define PIN_CTRL    2
#define PIN_ALT     3
#define PIN_SHIFT   4

#define MASK_CTRL   (1 << PIN_CTRL)
#define MASK_ALT    (1 << PIN_ALT)
#define MASK_SHIFT  (1 << PIN_SHIFT)

#define IDLE_DELAY  100

#define READ_PIN(key) digitalRead(PIN_##key) == LOW ? MASK_##key : 0
#define TOGGLE_KEY(key)                           \
 if (key ^ (pin_stat & MASK_##key)) {             \
   if (key) Keyboard.press(KEY_LEFT_##key);       \
   else Keyboard.release(KEY_LEFT_##key);         \
 }

unsigned int pin_stat;

void setup() {
  pin_stat = 0;
  pinMode(PIN_CTRL, INPUT_PULLUP);
  pinMode(PIN_ALT, INPUT_PULLUP);
  pinMode(PIN_SHIFT, INPUT_PULLUP);
  Keyboard.begin();
}

void loop() {
  unsigned int CTRL = READ_PIN(CTRL);
  unsigned int ALT = READ_PIN(ALT);
  unsigned int SHIFT = READ_PIN(SHIFT);
  if ((CTRL | ALT | SHIFT) == pin_stat) {
    delay(IDLE_DELAY);
    return;
  }

  TOGGLE_KEY(CTRL);
  TOGGLE_KEY(ALT);
  TOGGLE_KEY(SHIFT);
  pin_stat = CTRL | ALT | SHIFT;
  delay(IDLE_DELAY);
}

발판은 원래 프로토타이핑이니 만큼 오픈 마켓에서 파는 싸구려 2500원짜리 세개를 붙여 볼까 하다가 그래도 욕심부려서 돈 좀 더 써서 3개 일체형을 샀는데... 무게나 미끄러짐 방지면에서는 합격이나 철판 모서리 때문에 맨발로 쓰다가 잘 못하면 다칠 것 같기도 하다. 다치지 않도록 뭔가 주위에 둘러싸야 하긴 해야 할 듯.

사실 이 글도 새로 만든 발판을 이용해서 이맥스로 작성하고 있는 중이다. 물론 글 쓰는 중에는 그다지 CTRL ALT SHIFT을 쓸 일이 많지는 않고 SHIFT의 경우는 어지간하면 대문자가 연속으로 있는 문장을 쓰는 데만 활용하고 있어서 그런지 아직까지는 뭐 좀 어색하긴 하지만 그렇다고 못 써먹을 정도는 아니긴 하다. 물론 손 보다 느린 발판 때문에 좀 더 지연되는 작업 속도라든가, 언제든지 CTRL을 누를 대기를 하고 있어야 하는 오른쪽 발은 좀 긴장상태가 계속 지속 되는 것 정도는 불만스럽기는 하다. 발판 때문에 양반다리 같은 걸 잘 못하고 각잡고 앉아야 하는 건 장점인지 단점인지 잘 모르겠다 -_-. 이제 처음 써보는 거니 일단은 일주일 정도는 익숙해 지는 데 노력해 보고 Kinesis껄 사든지 아니면 이걸 빵판 말고 만능기판에 땜질해서 회사로 들고 가든지 해야겠지. 이건 발판이 좀 누를때 시끄러운 감이 있어서 들고 가도 괜찮을런지 모르겠다만.

mode-line-format 변경하기

DOoMSDaY — Fri, 21 Jul 2017 15:35:05 +0900

잠깐 powerline같은 걸로 갈아타 보기도 했으나 이쁘기만 하지 실속은 그다지 없어서 기본 mode-line을 써 왔다. 그러나 nyan-mode를 쓰다 보면 아무래도 필요 공간이 많아지는데, 별 쓸 데 없는 마이너 모드 리스트가 쌓이다 보면 정작 필요한 게 안보이는 사태가 발생하더라. 그래서 아예 내 입맞에 맞도록 싹 뜯어 보기로 했다.

일단 버퍼가 read-only인지는 확실하게 구분이 가능해야 한다. 오죽하면 기본 mode-line 쓸 때도 아예 my:read-only-mode라는 마이너 모드를 만들어 놓고 lighter도 씨뻘건 색으로 달아 놓도록 해 놨겠느냐 말이지. 이번에도 비슷하게 구별이 가능하도록 read-only일 경우 버퍼 이름의 배경색을 빨갛게 만들어 두었다. 사실 모르는 사람이 보면 이게 뭔가 하겠지만, 어차피 나만 잘 알아먹으면 됐지.

뭐 그 외에 내 경우 Emacs에서 System IME를 사용하지 않고 자체 IME를 사용하니까, 현재 버퍼의 IME 모드도 표시될 필요가 있고.... nyan-mode(!!!)와 vc-mode는 포기할 수 없는 것들 이다. 그래서 나름 간단하게 구성해 본 mode-line은 아래와 같다:

그리고 mode-line-format은 다음과 같다:

;; my custom mode-line (inspired from emacs-fu)
(defface my:mode-line-readonly-buffer-id
  '((t :inherit mode-line-buffer-id :background "red" :foreground "yellow"))
  "Used for highlight readonly buffer")

(setq-default
 mode-line-format
 (list
  " %I "        ; buffer size
  ;; modified
  '(:eval (propertize (if (buffer-modified-p) "* " "  ")
                      'face 'compilation-mode-line-fail))
  ;; relative position, size of file

  ;; buffer name
  '(:eval (propertize " %20b "
                      'face (if buffer-read-only
                                'my:mode-line-readonly-buffer-id
                              'mode-line-buffer-id)
                      'help-echo (buffer-file-name)))

  " "
  ;; line/column
  (propertize "%02l" 'face 'font-lock-type-face)
  ":"
  (propertize "%02c" 'face 'font-lock-type-face)
  " "
  ;; input method
  '(:eval (propertize (if current-input-method-title
                          current-input-method-title
                        "ENG")
                      'face '(:height 0.8)))
  " "
  ;; major mode
  (propertize "%m" 'face 'bold)
  ;; process status; eg. compilation buffer
  '("" mode-line-process)

  " "
  ;; nyan-mode!!!!!
  '(:eval (list (nyan-create)))
  " %p "        ; percent of buffer
  ;; vc-mode
  '(:eval (propertize (if vc-mode vc-mode "")
                      'face '(:foreground "sky blue" :height 0.9 :weight bold)))
  ))

(when (display-graphic-p)
  (setq-default nyan-wavy-trail t)
  (setq-default nyan-bar-length 24)
  (nyan-mode 1)
  (nyan-start-animation))

%-constructs 라고 하는 특수 문자열은 %b이면 버퍼 이름을 찍는다든가 하는 특수한 기능을 가지고 있다. C-h v mode-line-format RET 으로 살펴 보면 어떤 %-constructs가 정의되었는지 살펴 볼 수 있다.

fill-column-indicator를 쓸 때 popup이 깨지는 문제 수정

DOoMSDaY — Mon, 3 Jul 2017 23:51:02 +0900

fill-column-indicator를 사용하다 보면 은근히 짜증나는 경우가 많다. 특히 company-mode나 flyspell-popup같은 popup overlay을 사용하는 것들이 뜰 때 아래 그림처럼 레이아웃이 깨져 보이는 경우가 발생한다.

일단은 이게 popup을 그리는 쪽에 문제가 있어서 그런 게 아니고, fci-mode쪽이 문제인 것이라, 일단 workaround로 popup이 뜰 때 fci-mode를 끄는 수 밖에 없다. 사실 popup overlay를 쓰는 것들이 많지가 않아서 내 경우는 flyspell-popup과 company-mode만 좀 만져주면 되었다. Workaround를 적용하는 것은 공통적인 뭔가 있는 것은 아니고 일일이 각 모드마다 popup을 띄우는 함수에 advice 함수를 거는 수 밖에 없다.

;; Fix the problem of distorted popup of company
(defun my:company-fci-workaround (command)
  (cond ((and fci-mode
              (string= command "show"))
         (setq-local my:fci-mode-suppressed t)
         (turn-off-fci-mode))
        ((and my:fci-mode-suppressed
              (string= command "hide"))
         (turn-on-fci-mode)
         (setq-local my:fci-mode-suppressed nil))))
(advice-add 'company-call-frontends :before #'my:company-fci-workaround)

;; Fix the problem of distorted popup of flyspell-popup-correct
(define-error 'my:flyspell-fci-workaround-trap
  "A custom signal to run trap in my:flyspell-fci-workaround.")

(defun my:flyspell-fci-workaround (orig-fun &rest args)
  (condition-case nil
      (if fci-mode
          (progn
            (turn-off-fci-mode)
            (unwind-protect
                (apply orig-fun args)
              (turn-on-fci-mode)))
        (signal 'my:flyspell-fci-workaround-trap nil))
    (my:flyspell-fci-workaround-trap (apply orig-fun args))))
(advice-add 'flyspell-popup-correct :around #'my:flyspell-fci-workaround)

위와 같이 설정해 주면, flyspell-popup이나 company-mode의 popup이 뜰 때 fci-mode가 활성화 되어 있다면, popup이 뜰 때 잠깐 껏다가 popup이 사라질 때 다시 켜 주게 된다. 이거 말고도 truncate-lines을 끌 때 짜증나는 문제도 좀 있긴 한 데, 그건 나중에....

Gold Wireless Headset 이어패드 교체기

DOoMSDaY — Wed, 14 Dec 2016 15:14:12 +0900

예전에 한 번 사용기도 올리고 했던 Gold Wireless Headset을 아직도 잘 쓰고 있긴 하지만, 이런 타입의 인조가죽 이어패드의 고질적인 문제는 역시 피해갈 수 없는 것인가, 내 Gold 헤드셋 이어패드도 피복이 갈라져서 떨어져 나가는 현상이 발현되기 시작했다. 그냥 부스러기가 가끔 떨어지는 수준이 아니라 꽤 심각한 수준으로 부스러기가 떨어지는 데다 착용시 묻어나기도 해서 이어패드를 교체해야겠다는 생각이 들어 교체품을 수소문하기 시작했었다.

물론 가장 처음 찾은 것은 aliexpress에서 파는 전용 이어패드였다. 이게 공식 교체품인지는 잘 모르겠지만 (아마 아닐 듯) 이어패드 부분을 바로 빼서 교체할 수 있도록 플라스틱 부품까지 그대로 달려 있긴 하다. 다만 지금이야 가격이 좀 내렸긴 한데 고민하던 당시에는 23불 정도였던 터라 내가 99불짜리 헤드셋 이어패드 교체하려고 23불을 투자해야 하나 하는 생각도 들고, 이왕 교체할 거면 인조가죽 대신에 다른 재질로 쓰고 싶다는 생각 때문에 선뜻 이걸 주문하지는 못했다.

그러던 와중 구글 이미지 서치에서 발견한 것이 아마존의 HPAEC940에 달려 있는 유저 리뷰였는데, Gold 헤드셋에 Shure SRH940용 교체용 이어패드를 장착한 사진을 보고나니 이거다 싶었다. 그래도 이거하나 직구하자고 배대지 쓰려니 배보다 배꼽이 커지는 기분이라 다른 직구건에 묻어오느라 실제로 구입 결정 시기보다는 갖고 들어오는 게 꽤 오래 걸리긴 했다 -_-

아래는 구입한 HPAEC940. 실제 SRH940과 Gold 헤드셋의 구경이 동일하지는 않다. SRH940 자체가 좀 더 아래위로 긴 달걀 형태라면 Gold 헤드셋은 보다 원형에 가까운 구조이다.

기존 이어패드에서 폼 부분만 제거하고 플라스틱은 재활용해야 하기 때문에 폼 부분을 제거를 해야 한다. 특별히 도구가 필요하진 않고 손으로 제거할 수 있다. 기존 폼을 제거하고 새 교체용 이어패드를 이어패드 플라스틱부분에 장착하면 끝. 물론 아까 말한바와 같이 사이즈가 동일하지 않기 때문에 약간 늘이거나 억지로 폼을 맞춰 잡을 필요는 있다. 접착제로 고정해야 생각했지만 특별히 접착제는 없어도 고정은 가능한 정도. 그래도 약간의 이격이 있으니 나중에 맘에 안든다 싶으면 목공풀로 살짝 붙여 주면 되지 않을까 싶다.

음질에 대해서는 그다지 막귀인 내가 얘기해봤자 설득력이 있진 않을 것 같고, 착용감은 기존에 비해 좀 나아진 것 같다는 생각도 든다. 원래 이어패드가 뒤쪽이 더 두꺼운 형태였어서 앞뒤 두께가 동일한 HAPEC940으로 바꾸면 뒤쪽이 뜨는 느낌이 있지 않을까 우려했었는데 다행히도 그런 느낌이 거의 들지 않는다. 물론 교체하고 나서 외관상으로는 확실히 구경이 안 맞기 때문에 드는 위화감은 있어서 보기에도 원래것과 같은 느낌이라고는 하기는 어렵지만, 착용감 면에서 기존보다 월등히 좋다고는 하기 어려우나 인조가죽 보다는 벨벳쪽 재질이 좀 더 선호되는 측면이 있다. 뭐 어쨌건 부스러기 안 떨어지는게 (그리고 앞으로도 부스러기 걱정할 일이 없다는 게) 어딘가 싶다는 게 내 솔직한 심정.

Tramp Mode 소개

DOoMSDaY — Mon, 31 Oct 2016 20:40:01 +0900

이제 1년 반 남짓 Emacs를 쓰면서 가장 편리하고 매일 끊임 없이 사용하는 기능이라면 단연코 tramp이지 않을까 한다. 사실상 빌드 서버나 타겟에 있는 파일을 수정하겠다고 터미널을 띄우거나, 타겟에 접속해서 이제는 키 바인딩도 헷갈리는 VI를 실행하지 않아도 되는 이유이기도 하다.

Tramp Mode는 간략하게 설명하자면, 그냥 로컬 호스트의 이맥스를 통해 다른 리모트 서버의 파일을 읽거나 수정, 저장하는 일련의 편집 기능을 추상화된 네트워크 경로를 통해 할 수 있게 만드는 기능이다. 뭐 간단하게 말하자면 hifi라는 서버의 내 홈 디렉토리의 aa.txt를 수정하려면 /hifi:/home/ysjang/aa.txt를 열어서 편집하고 저장하면 알아서 네트워크를 통해 접속 버퍼에 파일 내용을 로드하고, 저장할 경우 다시 이걸 리모트 서버에다 저장해 주는 역할을 transparent하게 해 주는 기능이라 할 수 있다.

이게 왜 대단하냐 하면 일반적으로 ssh 등을 지원하는 리모트라면 굳이 protocol을 지정할 필요도 없이 사용할 수 있고, 지원하는 protocol 범위도 엄청나게 넓다. WINBIND는 물론이고 심지어 ADB까지도 지원할 정도니까... 그리고 그 말은 타겟의 파일 하나를 수정하기 위해 터미널로 접속해서 VIM도 아닌 VI를 띄워서 써야하는 상황 자체가 필요 없기도 하고^[각주:1], 터미널의 속도나 안정성이 편집 자체에 영향을 주지 않기 때문에, 느리거나 불안한 접속 환경에서도 일단 읽고 저장하는 단계만 잘 된다면 네트워크 환경에 스트레스 받지 않고 본인이 익숙한 곳이라 쓰고 Emacs라고 읽는다에서 작업을 할 수 있게 된다.

이렇게 대단한 기능이지만 사실 사용하기 위해 별다른 준비가 필요하지는 않다. 22.1 이후 버전이라면 GNU Emacs에 기본으로 들어있고, 사용법도 간략하게 M-x find-file, 혹은 C-x C-f을 실행해서 경로로 /프로토콜:서버주소:경로을 주면 된다. 만약 프로토콜을 특별히 지정하지 않는다면 tramp-default-method을 사용하게 된다. 도중에 패스워드 입력이 필요할 경우 패스워드 입력 프롬프트가 뜨기도 하는데 그건 그 때 입력하면 된다.

다만 Windows 환경에서 Emacs를 사용할 경우, ssh 프로토콜을 통해 tramp를 사용하고 싶다면 putty의 plink를 사용해야 한다. 다운 받은 plink.exe를 실행 PATH가 걸려 있는 적절한 위치에 넣어 준 다음 Emacs init script에 아래와 같이 넣어 주자.

(when (eq system-type 'windows-nt)
  (when (executable-find "plink")
    (require 'tramp)
    (setq-default tramp-default-method "plink")))

뭐 물론, 이거 안 넣고 /plink:remotehost:path 같이 해도 되긴 한다만.

embedded 해본 사람은 알겠지만 embedded에 Emacs는 커녕 VIM 도 안 넣어 놓는다. [본문으로]

rfcview.el : Emacs RFC Viewer

DOoMSDaY — Mon, 31 Oct 2016 19:11:07 +0900

얼마 전에 RFC를 좀 볼 일이 있어서 뒤지다가 웹 브라우저에서 읽기 참 불편하더라는 느낌이 있어 Emacs에서 읽고 싶다는 생각에 하나 만들게 되었다. Emacs용 RFC 뷰어는 뭐 세상에 없던 건 아닌데, reinventing wheel이건 뭐건 그냥 내 쓰기 편한 놈을 만들고 싶어서 rfcview.el라는 놈을 하나 만들었다.

기능은 뭐 별다른 건 없고, ietf.org에서 RFC index의 최종 업데이트일을 받아 보고 업데이트 되었다면 RFC 리스트를 갱신, 출력하고, 원하는 RFC를 선택하면 다운로드 받아서 보여주는 용도. 추가로 RFC 문서에서 highlighting도 좀 해 줬으면 좋겠는데 아직은 딱히 어떤식으로 해야 가독성이 높아질 지 잘 모르겠어서 고려 중이다.

그래도 구색 맞추겠다고 favorite이나 keyword search 같은 filter들을 좀 넣어놨더니 의외로 쓸만해서 스스로는 만족 중.

framemove.el : Emacs frame간 이동

DOoMSDaY — Sat, 25 Jun 2016 07:53:44 +0900

사실 Emacs를 frame 하나만 띄워서 쓰다보면 버퍼 저글링(juggling)을 심하게 해야 할 때 좀 귀찮은 구석이 있다. 게다가 여러개의 모니터를 사용할 경우 frame을 여러개 띄워 놓고 쓰고 싶긴 하지만 뭐랄까 frame간 이동이 귀찮아 지는 문제가 있다. 원래는 frame간에 이동할 때 C-x <left>이나 C-x <right>로 previous-frame, next-frame으로 이동하면서 썼지만 아무래도 window 이동은 windmove키를 쓰고 frame간 이동은 별도의 키를 쓰는 것이 그다지 맘에 들지 않았다.

그래서 당분간은 windmove의 좌우 이동키로 frame간에도 이동할 수 있도록 아래와 같이 짜서 사용하기도 했지만, 당시에는 frame-parameter 함수의 존재를 몰라, frame의 geometry 정보를 못 가져 오는 줄 알아서 사실상 키만 windmove키를 사용할 뿐이지 어차피 previous-frame, next-frame에 의존적이라 실제 프레임의 위치에 따라 직관적으로 이동하는 방법은 아니었다.

;; To use multi-monitor more usefully
(defun my:move-to-window-or-frame-left (&optional arg)
  (interactive "P")
  (let ((other-window (windmove-find-other-window 'left arg nil)))
    (if (and (display-graphic-p)
             (null other-window)
             (framep (next-frame)))
        (progn
          (select-frame-set-input-focus (next-frame))
          (unless (window-at-side-p (selected-window) 'right)
            (select-window (car (window-at-side-list (selected-frame) 'right)))))
      (windmove-left arg))))

(defun my:move-to-window-or-frame-right (&optional arg)
  (interactive "P")
  (let ((other-window (windmove-find-other-window 'right arg nil)))
    (if (and (display-graphic-p)
             (null other-window)
             (framep (previous-frame)))
        (progn
          (select-frame-set-input-focus (previous-frame))
          (unless (window-at-side-p (selected-window) 'left)
            (select-window (car (window-at-side-list (selected-frame) 'left)))))
      (windmove-right arg))))

뭐 다소 불편함이 있긴 했지만 위의 함수로 어쨌든 듀얼 모니터 환경에서는 쓸만하긴 했지만 그래도 직관성이 떨어진다거나 모니터가 더 많아지거나 위치가 좌우가 아닌 경우에 대해서는 아쉬움이 있긴 했다.

그러던 와중 Emacswiki를 뒤지다가 framemove.el을 찾아 냈는데, 입력하는 화살표 위치에 있는 frame으로 이동시키는 직관적인 인터페이스를 가지고 있더라. (사실 frame-parameter라는 함수가 존재하는지도 이걸 보기 전엔 몰랐다 -_-) framemove-hook-into-windmove을 non-nil로 설정하면 windmove의 키로 frame간 이동도 seamless하게 연동되어 아주 만족스럽게 쓰고 있다. 솔직히 위에 저것도 그냥 잘 찾아서 framemove.el을 미리 발견했으면 좋았을 껄 괜히 짜서 썼다는 생각마저 들기도 한다 ㅋㅋ

framemove.el의 주석에도 적혀 있지만, 설치는 아래와 같이 하면 되고,

(require 'framemove)
(framemove-default-keybindings)

windmove키와 연동되게 하려면

(require 'framemove)
(windmove-default-keybindings)
(setq framemove-hook-into-windmove t)

를 init script에 넣어 주면 된다.

쓰면서 발견한 한 가지 문제점은 frame이 전환되었을 때 이전에 focus를 가지고 있던 window가 여전히 선택되어 있는 문제인데, 다시 말해 오른쪽의 frame에 가장 오른쪽 window를 선택해 둔 상태에서 왼쪽 frame을 click한 다음 windmove 오른쪽 이동 키를 사용해서 오른쪽 frame으로 진입하게 될 경우, focus가 진입방향인 왼쪽이 아닌 여전히 오른쪽 window에 맞춰져 있는 현상이다. 사소하다면 사소하지만 은근히 내가 원하는 동작과는 좀 취향이 맞지 않아서 위쪽 내 코드에도 진입 방향의 첫번째 window를 선택하도록 하는 코드를 집어 넣었었다. framemove에서도 진입방향의 첫번째 window를 선택하도록 하려면 아래의 advice를 추가하면 된다.

(defun my:fm-next-frame (dir)
  "Select window at direction where the focus entered from."
  (let* ((opposite '((up . bottom) (left . right) (right . left) (down . top)))
         (from (cdr (assoc dir opposite))))
    (unless (window-at-side-p (selected-window) from)
      (select-window (car (window-at-side-list (selected-frame) from))))))
(advice-add 'fm-next-frame :after #'my:fm-next-frame)

Dark Soul 3 : Finale of souls series

DOoMSDaY — Mon, 23 May 2016 22:44:47 +0900

발매에 사 와서 1회차 엔딩보고 2회차 돌다말고 암령 침입만 주구장창 하다가 잠시 중단 중이다. 외전 같은 느낌의 2편에 비해 다크 소울3는 1편의 스토리와 세계관을 계승하고 있고, 시스템적으로도 2편보다는 1편에 따르고 있어서 1편을 한 입장에서는 좀 더 반가운 기분이 들긴 한다. 보스의 난이도는 이제 소울 시리즈에 익숙해서인지 실제로 난이도가 낮아서인지 잘 모르겠으나 전체적으로 꽤나 쉬워진 느낌으로 (물론 2편에서 메이스 쌍수로 다 씹어먹던 시절에 비할바는 아니지만) 엘드리치나 로리안 외에는 그다지 혼자서도 힘들다는 느낌이 들지 않았다. 아 물론 욤의 경우는 첫회차에는 일절 공략을 안 보고 플레이 하는 터라 스톰 룰러쓰는 지를 모르고 때려 잡아 보겠다고 애 좀 쓰긴 했지만... 뭐 그래도 못 잡을 지경은 아니었다 -_- (물론 1편에서 부러진 직검으로 수용소 데몬을 때려잡는 느낌이긴 했지만)

물론 필드 난이도 자체는 건재하고 악의적인 몹 배치들은 여전하지만 그 악랄함이 확실히 3편에서는 많이 무뎌졌다는 낌이 든다. 거기다 화톳불이 솔직히 너무 많다는 느낌마저 들 정도로 도처에 깔려 있고 숨겨진 화톳불도 거의 없다시피 해서, 예전 시리즈에서 레벨 몇 개는 올릴 만한 소울 들고 화톳불 찾아 헤메 다니다가 처음 들어가는 길을 들어갔더니 보스방이더라 (그리고 보스한테 죽고 다시 뛰다 또 죽어서 소울 날려 먹게 되더라...) 라는 상황도 나오기 어려울 뿐더러, 센의 고성이나 병자의 마을같은 토나오는 구간도 극히 적어서 사실 조금 팬 입장에서는 실망스러운 구석도 좀 있다. (적고 보니 이런게 아쉬운 점이라니...)

그러나 (데몬즈 소울 제외) 소울 시리즈를 겪어본 입장에서 이번 작은 꽤 의미 있는게 그래픽이나 프레임, 음악, 그리고 게임 볼륨까지 어느 하나 빠질만한 구석 없이 잘 채워 놓아 소울 시리즈 3부작의 대미를 장식할만한 의미 있는 작품이라 할 수 있다는 점으로, 사실 위에서 약간의 불평을 늘어 놓긴 했지만 이건 어디까지나 팬보이 입장에서의 약간 아쉬운 점을 늘어 놓은 것이지, 지금 와서 센의 고성 같은 곳 다시 몇번 들어가라면 그건 그거대로 빡칠 것 같기도 하다. -_-

또한 멀티 플레이!! 이것도 이번 작에서 칭찬 받아야 할 부분이라고 생각하는데, 이번 작은 암령이나 수호령 등 침입이 특히나 활성화 된 느낌이라 가끔 침입 플레이를 하다보면 백령 청령 수호령 암령 다 튀어와서 치고 받는 -_- 개판도 꽤 많이 경험할 수 있다. 아쉬 운 점은 무기 밸런스가 좋지 않아서(라고 쓰고 에스톡 개객기라고 읽는다) 에스톡에 대형 방패 끼고 오면 좀 짜증나긴 하나, 전부다 소위 사기급 세팅만 하고 있는 건 아니라서 PVP를 하다보면 다양한 세팅의 사람들과 대전할 수 있고, 또한 온라인 플레이 자체도 오히려 블러드본 시절보다 더 쾌적할 정도라 멀티 플레이에 흥미가 있는 사람이면 사람들이 많이 하고 있는 이 타이밍에 즐기는 것이 꽤 재미있을 것이다.

어쨌건 발매일 이후로 애 재우고 와이프 눈치보면서 한 달 동안 즐겁게 같이 논 듯 하다. 첨언하고 싶은 점은, 2편은 사실 별 필요 없을 것 같지만 가급적 1편을 안 해보신 분들은 1편을 플레이한 그 후에 플레이를 하면 좀 더 재미있게 즐길 수 있을 것 같긴 한데.... 지금 와서 1편은 좀 하기 그렇긴 하겠지.

ido에서 helm으로 넘어오다

DOoMSDaY — Tue, 17 May 2016 23:34:42 +0900

거의 이맥스를 사용하기 시작하면서부터 줄곧 ido와 smex를 사용하고 있었는 데, 며칠 전 helm-cmd-t에 혹해서, 사실 더 정확히는 VIM의 command-t에 혹했다는게 맞겠지만, 어쨌건 helm으로 넘어가 보기로 했다. 아직 초기라 거의 튜토리얼 보고 나름 필수 패키지라는 것들만 사용해보고 있기는 한데, 뭐 ido 시절에 비해 확실히 편리한 점이 있기는 있네. 일단은 약간의 시행 착오 끝에 아래의 패키지를 추가해서 쓰고 있다:

helm : helm 메인 패키지
ac-helm : auto-complete를 helm 인터페이스를 사용하도록 하는 패키지
helm-projectile : projectile과 helm을 연동해 주는 패키지
helm-ls-git : git 파일이나 버퍼를 helm 인터페이스로 검색하는 패키지

정작 원래 사용하려고 했던 helm-cmd-t는 기능이 helm-ls-git나 helm-projectile과 거의 겹치지만 실제로 사용해 보니 위의 둘 보다 별로라서 사용하지 않게 되었다. flx를 helm에 연동한 helm-flx도 써보긴 했는데 이걸 쓰니 helm-M-x의 응답시간이 현저하게 느려지는 것 같아서 이것도 조금 쓰다가 폐기해 버렸다.

;; utils-helm.el

;; Written by Yunsik Jang <doomsday@kldp.org>
;; You can use/modify/redistribute this freely.

(require 'helm)
(require 'helm-config)
(require 'helm-projectile)

(let ((map helm-map))
  (define-key map (kbd "<tab>") 'helm-execute-persistent-action) ; rebind tab to run persistent action
  (define-key map (kbd "C-i") 'helm-execute-persistent-action) ; make TAB work in terminal
  (define-key map (kbd "C-z") 'helm-select-action)
  (define-key map (kbd "M-f") 'helm-next-source)
  (define-key map (kbd "M-b") 'helm-previous-source))

(setq helm-split-window-preferred-function 'helm-split-window-default-fn
      helm-move-to-line-cycle-in-source t
      helm-ff-search-library-in-sexp t
      helm-scroll-amount 8
      helm-ff-file-name-history-use-recentf t
      helm-M-x-fuzzy-match t

      ;; projectile
      projectile-enable-caching t
      projectile-file-exists-remote-cache-expire (* 10 60)
      projectile-completion-system 'helm
      projectile-switch-project 'helm-projectile)

;; replace projectile prefix key
(let ((map projectile-mode-map))
  (define-key map projectile-keymap-prefix nil)
  (define-key map (kbd "C-x p") 'projectile-command-map))

(projectile-global-mode)
(helm-autoresize-mode 1)
(helm-projectile-on)

;; http://emacs.stackexchange.com/questions/2563/helm-search-within-buffer-feature
(defconst my:helm-follow-sources
  '(helm-source-occur)
  "List of sources for which helm-follow-mode should be enabled")

(defun my:helm-set-follow ()
  "Enable helm-follow-mode for the sources specified in the list
variable `my-helm-follow-sources'. This function is meant to
be run during `helm-initialize' and should be added to the hook
`helm-before-initialize-hook'."
  (mapc (lambda (source)
          (when (memq source my:helm-follow-sources)
            (helm-attrset 'follow 1 (symbol-value source))))
        helm-sources))

;; Add hook to enable helm-follow mode for specified helm
(add-hook 'helm-before-initialize-hook 'my:helm-set-follow)

(provide 'utils-helm)

위는 helm 설정 파일인데, 아직 거의 처음 사용하는 것이라 사실 거의 튜토리얼 기본 셋 정도이다. 다만 마지막의 my:helm-set-follow 함수는 stackoverflow에서 주워 온 건데 helm-occur에서 선택한 항목의 위치를 원래 버퍼에서 추적해 주도록 하는 것으로, 이건 정말 쓸만하다. 보통은 버퍼 내의 정규 표현 검색을 위해서 helm-swoop을 많이 사용하지만 아직까지는 my:helm-set-follow과 helm-occur 조합만으로도 쓸만해서 helm-swoop은 설치하고 있지 않다.

오늘로써 helm으로 넘어 온 지 3일 정도 된 것 같은데, 현재 시점에서 helm에 대한 감상은... 뭐 일단 쓸만한 게 좀 있어서 좋긴 하지만 가끔 의도한 대로 동작하지 않는 경우가 종종 있어서 계속 쓰게 될 지는 아직 좀 고민해봐야 할 것 같다. candidates source도 auto-complete처럼 그냥 ac-sources에 등록만 해놓으면 엔진에서 알아서 가져다 보여주거나 쓰는 게 아니라, 이건 좀 목적에 따른 source를 helm이라는 공용 인터페이스를 사용해서 선택할 수 있게 하는 형태라 키 바인딩이 좀 더 번잡해 진 것 같기도 하고...

Emacs에서 End of Line 타입 변경을 간편하게!

DOoMSDaY — Wed, 11 May 2016 23:19:02 +0900

그냥 전부 다 line-feed^[각주:1]로 통일 하지 왜 굳이 EOL(End of line)을 OS 마다 다르게 하는 지 모르겠지만, 어쨌건 Windows에서는 line feed앞에 carriage return^[각주:2]을 넣어서 라인을 구분하게 했고, Mac에서는 또 carriage-return만으로 구분하도록 했다.^[각주:3] 사실 이건 그냥 해당 OS에서만 편집을 하고 사용하게 되면 문제가 없긴 하지만, 편집한 파일을 다른 OS에서 열어본다거나(다행히 Emacs에서 열어본다면 별 문제 없겠지만) 혹은 tramp를 통해 remote에서 스크립트 파일 같은 걸 작성하다보면 문제가 되는 경우가 종종 발생한다.

Emacs에서도 VIM 처럼 EOL 타입을 지정해 줄 수 있긴 하지만, VIM의 fileformat처럼 EOL 타입을 위한 전용 변수가 있어서 여기다 dos나 unix를 지정하는 것으로 모드 전환이 되는 것이 아니라, 현재 버퍼의 encoding type에 suffix로 지정을 해 주는 방식을 사용한다.C-h v나 M-x describe-variable RET을 통해 buffer-file-coding-system의 값을 살펴 보면 현재 버퍼에 지정된 encoding type과 EOL 모드를 알 수 있다. 가령 내 경우 윈도우에서 일반적인 버퍼에 korean-iso-8bit-dos가 변수의 값으로 지정되어 있는데, 여기서 앞부분이 coding system, 즉 버퍼의 encoding 형식을 지정하는 것이고 마지막 -dos 부분이 EOL 타입을 의미하는 것으로, 만약 encoding은 그대로 두고 EOL 타입을 unix 스타일로 바꾸고 싶다면 korean-iso-8bit-unix를 지정해 주면 되는 것이다.

그러나 이게 상당히 귀찮다는 게 문제이다. 단순히 EOL 타입만 변경하고 싶어도 C-h v buffer-file-coding-system RET을 입력 해서 현재 변수 값을 살펴 보고, 가령 현재 coding system이 korean-iso-8bit라는 걸 확인한 다음, M-: (setq buffer-file-coding-system 'korean-iso-8bit-unix) RET을 입력해줘야 한다. 생각만해도 귀찮음이 몰려 오지 않나? 이게 만약 파일 하나가 아니라면...

없으면 만들면 되지. 아래 소스 처럼 cheol이라는 interactive function을 정의했다. 현재 버퍼의 coding system은 그대로 유지하고 EOL 설정만을 unix, dos, mac 중 입력된 값에 따라 바꿔 준다.

(defun my:read-eol-type ()
  (let* ((os (cond
              ((eq system-type 'ms-dos) "dos")
              ((eq system-type 'windows-nt) "dos")
              ((eq system-type 'darwin) "mac")
              (t "unix")))
         (cur-eol (or (with-current-buffer (current-buffer)
                        (let ((cs (symbol-name buffer-file-coding-system)))
                          (when (string-match "\\(.+\\)-\\(unix\\|dos\\|mac\\)\\'" cs)
                            (replace-match "\\2" t nil cs))))
                      os))
         (readfunc (if (and (boundp 'ido-mode) ido-mode)
                       #'ido-completing-read
                     #'completing-read)))
    (values (apply readfunc `(,(format "EOL Type (current: %s): " cur-eol) ("unix" "dos" "mac") nil t
                              "" nil ,os)))))

(defun cheol (eol-type)
  "Change buffer's EOL to preferred one in given OS"
  (interactive (my:read-eol-type))
  (let ((cs (format "%s-%s" (with-current-buffer (current-buffer)
                              (let ((cs (symbol-name buffer-file-coding-system)))
                                (if (string-match "\\(.+\\)\\(-unix\\|-dos\\|-mac\\)\\'" cs)
                                    (replace-match "\\1" t nil cs) cs)))
                    eol-type)))
    (unless (member (list cs) coding-system-alist)
      (error "Unsupported coding system: %S" cs))
    (setq buffer-file-coding-system (intern cs))
    (set-buffer-modified-p t)))

my:read-eol-type 함수는 입력의 자동 완성을 위해 작성한 것으로, 입력을 간단하게 하는 역할도 있지만 cheol 함수의 eol-type 인자가 반드시 unix, dos, mac 중 하나로 들어오도록 제한하는 역할도 한다.^[각주:4]

실행해서 EOL 타입을 변경해 보면 mode-line에 (Unix) 등으로 현재 OS의 기본과 동일하지 않을 경우 지정된 EOL 타입이 표시되고, VIM처럼 격렬한 ^M의 향연이 펼쳐지는 대신 모든 라인에 변경된 정책을 적용해버린다. 그러나 이러한 변경은 버퍼에만 해당 되는 것으로 실제 파일에는 적용되지 않았기 때문에 결국 저장을 해야 하는데, 단순히 buffer-file-coding-system을 변경한 것은 버퍼 내용을 건드린 것이 아니라 modified flag가 켜지지 않는다. 기껏 EOL 타입 바꿔 놓고 저장이 안되는 상황이 벌어질 수도 있는 것이다. 이것이 cheol 함수 마지막에 (set-buffer-modified-p t)를 집어 넣은 이유로, EOL 타입 변경 자체도 변경점으로 보고, 관련한 변경 사항이 유실되지 않도록 처리했다.

이제 EOL 타입 변경이 필요할 때, 가령 unix 타입으로 변경한다면 M-x cheol RET u TAB RET과 같이 입력 해주면 되니 한결 편해졌다. 키 바인딩까지 추가하면 더 쉽게 변경이 가능하겠지만 EOL 타입 변경이 키 바인딩을 굳이 지정할만큼 자주 쓰이는 것도 아니고, 뭐 이 정도면 쓰기에 충분할 것 같다. 아쉬운 점은 Mac의 경우 버전 9까지만 mac 타입을, 이후로는 unix를 OS 기본 타입으로 설정하고 싶지만 현재로써는 system-type의 darwin 값 외에는 딱히 참조 할만한 값이 없어서 그냥 다 mac 타입으로 지정해 놓고 있는 것이긴 한데... 어차피 요즘은 다 10 쓰니까 그냥 darwin인지 체크하는 라인은 삭제하는 게 나을지도 모르겠다. 뭐 난 맥 안쓰니까 상관 없을 듯 -_-

ASCII Code 0x0A, escape sequence로는 보통 '\\n'으로 표기함 [본문으로]
ASCII Code 0x0D, escape sequence로는 보통 '\\r'로 표기함 [본문으로]
Mac OS X 9까지는 이렇고, 10부터는 unix처럼 line-feed만으로 EOL을 표기하고 있다 [본문으로]
completing-read의 require-match 인자를 통해 지정된 값들 이외의 것이 입력될 경우 입력이 완료되지 못하게 한다. 자세한 사항은 Emacs Lisp Manual의 19.6.2 Completion and the Minibuffer를 참조하기 바란다. [본문으로]