2017년 12월 5일 화요일

Markdown과 Stackedit

차례


시작하며….

Markdown으로 글을 정리 하는건 다른 문서 편집 문법에 비해 편하다는 것을 앞선에서 이야기 드렸습니다.

그럼 이걸 어떻게 써야 할까요????

이걸 이용해서 Blogger에는 어떻게 올려야 할까요???

그 방법에 대해서 이야기 하도록 하겠습니다.

Stackedit

기본적으로 Blogger에서는 Markdown을 지원 하지 않습니다.

그러니까… 열심히 Markdown으로 입력을 했지만 Blogger에서는 형태를 잡을 때 다시 해야 한다는 거죠.;;;

제가 처음으로 Markdown을 사용해야 하고 싶다고 마음 먹었을 때 가장 먼저 한거는 Markdown을 Blogger에 적용하는 방법을 찾는 것이었어요.

이곳 저곳 돌다가 가장 효과적이고 사용이 편리한 것은 Stackedit 였습니다.

https://stackedit.io/

Viewer로써와 Blogger에 적용하는 방법 모두 최강입니다.

어떤 점이 최강인지 하나씩 볼게요.

도움말

https://stackedit.io/editor# 에 접속을 하게 되면 가장 처음에는 접속 하는 것이라면 “Hello!”라는 타이틀과 함께 사용자를 반겨 주지요.

아래의 그림이 일부의 모습입니다.

이 Hello의 글만 읽더 라도 Markdown을 사용하는 법에 대해 아주 간단하게 알 수 있게 되지요.^^

어제 제가 열심히 적은 내용들이 사실은 모두 필요 없었어요..;;;;

그래도 저를 위한 자료라고 생각해야죠.ㅎ

실시간 변환

위의 그림에서 보던 거 처럼 중간을 중심으로 왼쪽은 편집기이고 오른쪽은 뷰어예요.

사용할 텍스트 편집기가 없을 때는 직접 적으면 원하는 형태가 나오는지 확인을 할 수 있어요.

Import from disk

아시는 분은 아시겠지만 저는 편집기 중에 Vim을 선호합니다.

Vim으로 작성을 한 후에 내용을 복사하고 Stackedit에도 붙여넣기로 글을 전달할 수 있지요.

그런데 파일을 직접 Import를 한다면 현재 작성하는 파일이 아니라 예전에 작성했던 파일들도 쉽게 확인 할 수 있겠죠??

우측의 #을 클릭하면 Import from disk 버튼이 있어요.

아래 그림 처럼요~

클릭 후 원하는 파일을 선택 하거나 Drag를 해 주면 원본은 좌측에, 우측에는 Viewer 형태로 바로 나오게 되죠.

아직까지는 파일에 대한 Refresh가 되는건 아닌거 같아요.

뭐.. 나중에는 되지 않을까요??

그럼 Vim으로 바로 수정 한 후에 Stackedit로 Refresh를 하여 바로 확인이 가능 해질거 같아요.

쉬운 Publish

이 부분이 가장 마음에 드는 것 중에 하나였어요.

Blogger를 하려면 기본 적으로 Blogger에 가서 “글쓰기”를 눌러서 원하는 글을 적고 저장을 하게 되죠.

그런데 Stackedit의 좌측 상단의 # 표시를 누르고 Publish까지 눌러 보세요.

클릭을 하면 Blogger와 업로드 할 수 있는 Web 사이트들이 나와요.

Blogger를 클릭 하시면 입력이 필요한 화면이 나오죠.

원하는 URL이나 수정을 원하실 때는 PostID까지 입력을 하시고 OK를 누르시면 바로 업로드 혹은 업데이트가 되요.

그리고 원하는 Web 사이트에 동일한 내용으로 올릴 수도 있지요~

이거 대박 아닌가요?????

어디에서도 동일한 형태로 올려 주니까요!!!! ^^

하지만… 혹시 아세요??

단순하게 글만 올리면 Blogger에서의 라벨은 어떻게 올려야 할까요????????

매번 업로드를 하고 라벨은 수정을 해야 하는건가요??

만약에 그래야 했다면.. 저는 금방 포기 하고 말았을거예요.ㅠ

Stackedit는 그렇게 하지 않아도 되는 거겠죠?? ㅋㅋ

마치며….

오늘 다 적으려고 했는데….

생각보다 많이 길어 졌네요.

제가 늦게 퇴근해서 글 적는 시간이 적었어요.;;

Blogger에 올릴 때 타이틀과 라벨 부분은 내일 다시 완료 하도록 하겠습니다.

감사합니다.

2017년 12월 4일 월요일

Markdown의 기본

차례


시작하며….

한동안 정리를 하면서 단순 Text로 글을 정리 한다는게 매우 불편하다는 생각을 했어요.

나중에 다른 곳에 글을 올린다고 할 때 원본글은 있지만 글자의 크기나 이미지의 링크 등을 일단 txt로는 관리 하기 너무 어렵더라고요.

그러니 만약에 다른 곳에 글을 옮긴다고 하면 또 다시 해당 사이트에 맞게 구조의 편집을 다시 해야 하더라고요.

그런 생각을 하니 갑자기 귀찮다는 생각이 들더군요.

그래서 이것 저것 찾다가 괜찮은 택스트 편집 문법인 Markdown을 찾게 되었네요.

이 편집 문법이 Html 처럼 복잡 하지 않고 제가 사용할 정도까지는 딱!! 적당했어요.

Markdown의 장점

이제 Markdown을 사용한지는 별로 되지 않았지만 그래도 제가 생각하는 장점은 다음과 같아요.

  1. 짧은 명령어
  2. 많은 Viewer
  3. Github 연동

1. 짧은 명령어

우선 기본 문법이 많지 않고 사용하는 방법이 굉장히 쉬워요.

  • Test1
  • Test2
  • Test3

예를 들어 위 처럼 html에서는 list를 주려고 하더라도.

<li> Test1
<li> Test2
<li> Test3

으로 <li>을 반복적으로 적어줘야 하지만.. Markdown은 아래처럼만 적으면 되요.

* Test1
* Test2
* Test3

3글자를 더 입력하지 않는다는게 얼마나 편한 건지 모르겠어요.^^

2. 많은 Viewer

Markdown이라는거 자체가 단순 문서 편집 문법을 가져서 그런지 생각보다 Viewer가 많더라고요.

Chrome 같은 곳에서 확장 기능도 있고요.

그리고…

저는 그냥 Vim으로 보는 것도 나쁘지 않은거 같아요.^^

Markdown Syntax in Vim

위의 이미지는 지금 작성하는 글의 Syntax가 포함된 화면이예요.

편집기는 Vim이고요.

Syntax를 이용하여 Markdown의 문서를 조금은 이쁘게 볼 수 있어서 단순 Text 보다 좋은거 같더라고요.

3. Github 연동

사실 Markdown이라는 용어를 알게 된것도 Github를 하면서 였어요.

하던 일만 하니(저는 임베디드쪽에서 일을 하고 있어요~) 웹쪽이나 어플 쪽은 까막눈이죠.ㅎㅎ

그러다가 Github에 README.md를 작성해야 한다는데 “이게 뭔가요..” 했지요.;;

처음에는 무관심하게 지나쳤는데 최근에 블로그를 하면서 찾다 보니 이게 저한테 맞는다는 생각을 했어요.

그리고 Git도 같이 사용하려고 했는데 Markdown이 Github는 기본 제공이 되더라고요!!

즉, 제가 모든 문서를 Markdown으로 작성을 한다면 특별한 Viewer 없이도 양식대로 볼 수 있는거더라고요.

지금 하고자 하는 것들이 모두 맞아 떨어 지게 된거죠.^^


위의 장점들은 저의 개인적인 장점들이니 다른 분들은 다른 장점 혹은 단점을 가지고 계실수도 있어요~

Markdown의 문법

기본 문법

사실 지금도 고민이예요.

너무나 많은 곳에서 Markdown 문법을 알려주고 있는데..

나도 여기에 적어야 하나…

아니면 링크만 열결을 해야 하나..^^;;

일단 가장 기본적인 Markdown의 문법은 아래 사이트에서 확인을 하시면 될거 같아요~

마크다운의 사용법과 정보

그외 문법

위에 없는 문법 중에 자주 쓸거 처럼 보이는거 몇개만 더 알려 드리면 다음과 같아요.

Code 부분

    ```javascript
        userCustom.onReady = function() {
            /* PlantUML Prepare */
            previewContentsElt = document.getElementById('preview-contents');
            $.getScript('//cdn.rawgit.com/dankogai/js-deflate/master/rawdeflate.js', makeUml);
        };
    ```

위 처럼 입력을 하고 Viewer로 보면 아래 처럼 나와요.

    userCustom.onReady = function() {
        /* PlantUML Prepare */
        previewContentsElt = document.getElementById('preview-contents');
        $.getScript('//cdn.rawgit.com/dankogai/js-deflate/master/rawdeflate.js', makeUml);
    };

신기하지 않나요?? ^^

Table

  |       | 철수   | 영희   |
   ----- | ------ | ------ 
  | 국어  | 100    | 80     |
  | 영어  | 90     | 90     |
  | 수학  | 80     | 70     |

Table도 그릴 수 있어요.

위처럼 작성을 하게 되면 아래 처럼 그림을 그려주죠.

철수 영희
국어 100 80
영어 90 90
수학 80 70

저는 이런게 왜이렇게 신기하고 좋은지 모르겠네요.ㅎㅎ

아.. 그리고 위의 테이블은 Viewer 마다 조금씩 문법이 다를 수 있어요~

마치며….

오늘은 Markdown에 대해 이야기 해 보았어요.

아직 편한건 잘 모르겠지요?? ^^;;;

하지만 슬슬 왜 제가 이걸 사용하게 되었는지 또 설명을 드릴게요.

오늘도 감사합니다.

2017년 12월 3일 일요일

Git의 기본

차례


시작하며….

지금까지 사용했던 형상 관리 툴을 보면 ClearCase, Perforce, SVN 정도가 될 거 같아요.

Git은 회사에서 사용하지 않다 보니까 잘 사용하지 않게 되더라고요.

그런데 이번에 Vim과 Plantuml등을 정리하면서 정리 내용을 Blog에 올리고는 있지만 이 글들을 좀 더 버전 관리라는 것을 하고 싶었죠.

그러다가 겸사겸사 Git으로 버전 관리를 하자라는 결정을 내리고 배우기 시작 했지요.

그렇게 Git을 알아 가니 이게 재미있더라고요.

기존 형상 관리 툴과는 다른 점도 나름 끌리기도 하고요.^^

그렇게 알게 된 점들을 여기에 정리하려고 합니다.

하나라도 끝내면서 다음을 진행해야 하는데…

하고 싶은 것만 많은 건 아닌지…

그리고 Git은 금방 끝내겠습니다!!!!
(제가 아는게 전문가 수준은 아니예요.^^;;;)

Git과 다른 툴과의 용어 차이들

처음 Git을 보면서 가장 어려웠던 점은 용어 였어요.

다른 형상관리 툴에서 사용하던 명령어나 용어들과 다른 점이 많았지요.

아마 처음에 add 라는 명령어 때문에 고민에 빠졌던 거 같아요.

add더하기 잖아요???

그래서 처음에 저 명령어를 보았을 때 신규 파일을 추가 하는 거라고 생각했어요.

근데 아니더라고요….;;;

이건 금방 아래에 설명을 드릴게요.

checkout 도 뭐지라는 생각을 들게 했죠.

checkincheckout은 다른 툴에서는 수정을 하고 수정을 완료 됨을 나타내곤 했지요.

그런데 Git에서는 Branch를 변경하는 거였어요.

저런 용어 정리 때문에 처음에 “Git은 어려운거!!!” 라는 편견을 가지고 있었죠.

그러다가 이제 필요하기 시작하니 기초부터 차근차근 다시 배우기 시작한 거죠.

기초 부터 다시 하니 Git에 대한 편견도 많이 사라지고 오히려 Git이 멋져 보이더라고요.

지금 이 글도 Git에 올리면서 쓰고 있을 정도니까요..^^

그럼 Git이 무엇일까요????

Local?? Remote?? Repository??

용어 정리가 필요하겠죠??

우선 저의 정의나 설명이 정확하지 않을 수 있다는 것을 말씀드립니다.;; ㅎㅎ

필요한 것만 배운 상태라 기본 원리와는 많이 다를 수 있어요.^^;;


Git은 위의 그림처럼 크게 두 가지로 나눌 수 있는 거 같아요.

제가 보았을 때의 구분법은 다음과 같죠.

  • Local : 개인이 작업 하는 공간
  • Remote : Backup을 위해 자료가 저장되는 공간


각각을 설명 드리기 전에 바로 Local에 있는 내용도 설명해 드릴게요.


위 처럼 Local과 Remote의 역할을 정의 하다 보니 처음에는 Remote의 이해 되지 않았어요.

타 버전관리 툴을 보게 되면 보통 서버들이 버전들에 대한 정보를 모두 가지고 있어요.

버전에 대한 소스 파일들이나 다른 메타데이터들을요.

그런데 Git에서는 Remote라는 건 단순 백업 서버라고 하니 이때부터 맨붕에 빠져 있게 되었죠.

그럼 그런 버전 정보들은 어디에 보관되어 있을까요?

답을 바로 이야기 드리면 Local 영역의 Repository에 저장된 거죠.

그러니 History나 버전별 소스들이나 모두 Local에 있다는 거죠.

즉… 네트워크로 연결할 수 없는 비행기 안이나 산골 지방에서도 Git으로 버전 관리를 할 수 있는 거죠.

이건 정말 큰 장점 중에 하나 아닐까요????

git의 기본 명령어

상태에 대해 간단히 보았으니 기본적인 명령어를 적어 보도록 하겠습니다.


위와 같이 Local에서의 상태의 이동 명령어를 간략하게 적어 보았습니다.

하나씩 설명을 해 드릴게요.

1. git init

우선 git은 모두 설치되어 있고 터미널에서 사용할 수 있다고 가정하고 진행하겠습니다.

만약에 Git으로 프로젝트를 관리 하고 싶다면 우선 해당 프로젝트의 디렉토리로 이동을 해요.

cd $ProjectDirectory
git init

그리고 init 명령어로 해당 디렉토리는 Git이 관리 한다고 생각하면 돼요.

2. 파일 추가와 상태 확인(git status)

파일을 하나 추가해 보죠.

echo TEST > A.txt

그럼 A.txt가 Working Directory라는 영역에 있는 거라고 생각하면 돼요.

지금 파일을 생성했는데 현재 상태가 궁금하겠죠?

그럼 상태를 한번 볼게요.

git status라는 명령어를 입력하면 되요.

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    A.txt

nothing added to commit but untracked files present (use "git add" to track)

위처럼 나오지요?

간단한 영어니까 읽어 보면…

Untracked files가 있는데 그 파일 이름이 A.txt 라네요.

지금 저 파일이 Working Directory 상태라고 생각하면 돼요.

3. git add A.txt

Working Directory 상태에서는 말 그대로 작업을 하는 상태예요.

지금 이 상태를 이제 거의 완료 했다고 가정한다면 이제 버전 관리를 해야겠지요???

그럼 Repository 쪽으로 이동해야 하는데 중간 단계인 Staging Area로 먼저 이동을 해 두어야 해요.

git add 파일명

위 명령어를 적게 되면 Staging Area로 이동하게 돼요.

다시 상태를 볼까요???

$ git status
On branch master

No commits yet

Changes to be committed:
  (use "git rm --cached ..." to unstage)

    new file:   A.txt

변경 사항이 있는데 그건 앞으로 commit을 해야 할 거라네요.

그 파일은 A.txt라고 적혀 있고요.

이제 남은 건 Commit 하는 것만 남았네요.^^

4. git commit -m ‘메시지’

모든 수정이 완료된 상태이니 이제 Repository로 이동시키고 버전 관리를 할 수 있도록 하면 되겠지요?

git commit

위 명령어를 치면 Staging Area에 있는 모든 파일이 Repository로 이동하게 되는데…

메시지를 입력하기 위해 Vim이 자동으로 실행 돼요.

메시지를 입력하고 Vim을 종료하면 되는데 귀찮을 수 있으니 옵션인 -m을 입력 하면 Vim 실행 없이 바로 메시지가 입력 돼요.

git commit -m '메시지'

위와 같이 입력 하면 되지요.

5. 상태 확인

Working Directory에도 없고 현재 버전 관리가 어떻게 되고 있는지 확인을 해 봐요.

status는 간단하죠??

$ git status
On branch master
nothing to commit, working tree clean

위 처럼 이제는 Commit 할 것도 없고 Working Tree도 깨끗하다고 하네요.

Working Tree는 Working Directory를 이야기 하는 거예요.

그럼 버전 관리의 확인은 어떻게 될까요??

log라는 명령어를 입력하면 돼요.

$ git log
commit d03e82eadca57c205366eee6375a4c19e0e297a7 (HEAD -> master)
Author: 사용자이름 <사용자이메일주소>
Date:   Commit한 시간

    Add A.txt

위처럼 나올 거예요.

그러니까 Author의 정보를 가진 사람이 Date 시간에 무슨 일을 했는데…

그때 입력한 메시지는 “Add A.txt”네요.

마치며….

가장 기본적인 Git에 대해 나열했네요.

  • git init
  • git status
  • git add 파일명
  • git commit -m ‘메시지’
  • git log


하지만 저 명령어 들만이라도 익숙해진다면 어디를 가더라도 Git을 할 수 있다고 해도 될 거 같습니다.

확장 기능들이 더 많지만 가장 기본부터 차근차근 하자고요.^^

2017년 11월 28일 화요일

Vim의 기능; 검색

시작하며....


제목을 보면 어떻게 보면 이상하다는 생각이 들어요.

다른 문서 편집기 보면 가장 간단한 것 중의 하나가 검색이지요.

다른 윈도우 프로그램은 기본 적으로 Ctrl+F를 누르면 검색이 되는데...

이걸 왜 지금에서야 하는지 이상하게 여길 수 있지요.

검색만을 주제로 할 만한 게 있는지도 의아해할 테지만...

Vim이 일반 프로그램과는 차이가 난다는 것을 아실테니까 더 알아야 하는 점들이 있겠지요~

바로 진행을 해보도록 하겠습니다.


기본 검색 명령어


Command-line을 진입하는 방법은 보통은 두 가지를 많이 이야기하죠.

하나는 명령어 실행이고 하나는 검색입니다.

명령어 실행은 ":"를 입력하고 필요한 명령어를 바로 입력한 후에 엔터를 입력하면 된다는 걸 모두 알고 계시죠.

그럼 검색은 뭐가 있을까요?

보통 두 가지를 이야기하는데 아래와 같습니다.


  • / : 다음(우측 아래) 방향으로 검색
  • ? : 이전(좌측 위쪽) 방향으로 검색


"/"나 "?"를 입력한 후에 단어를 입력하게 되면 단어에 대해 검색을 하게 됩니다.

그럼 검색한 내용에 대해 highlight가 설정 되어서 검색한 단어를 쉽게 볼 수 있어요.
(원치 않는다면 설정을 변경 할 수도 있습니다.)

그리고 아래의 명령어로 검색한 단어의 다음으로 이동하게 됩니다.

  • n : 검색한 정 방향으로 이동
  • N : 검색한 역 방향으로 이동


n, N이 그것인데요.

위에 설명한 거처럼 각각 정방향과 역방향으로 이동하게 됩니다.

즉, "/"로 검색을 했을 때 n을 누르면 우측 아래 방향으로 다음 단어를 찾게 되고 N은 반대 방향이겠죠.

하지만 "?"로 검색을 했을 때는 n을 누르면 정방향인 좌측 위쪽으로 다음 단어로 이동하게 돼요.

한번 해 보시면 어렵지 않을 거예요.

하지만 자꾸 헷갈린다 싶으면.. 그냥 "/"만 알고 계세요.

그럼 n은 오른쪽 아래 방향으로, N은 왼쪽 위 방향으로만 이동하니 이해하기는 어렵지 않게 되죠.

위에 처럼 방향을 이야기하면 자꾸 어려워지니 다음부터는 방향을 제어하는 명령어는 n과 N으로만 알고 있어 주세요.

그러면 오른쪽 아래으로만 검색하는 명령어를 알면 원하는 방향으로 검색을 할 수 있을테니까요.


커서 위의 단어 검색


타자 치는 걸 힘들어하시는 분들이 많을지 모르겠네요.

저는 타자가 빠른 편이 아니라 "/"를 누르고 찾고 싶은 글자를 치는 게 귀찮더라고요.

그리고 보통 글의 내용 중에 나오는 글자를 검색하는 경우가 많으니 커서 위의 글자를 바로 검색 해주는 명령어는 없을까요??

당연히 있지요..ㅎㅎ


  • * : 커서 위의 단어를 단어 단위로 검색
  • g* : 커서 위의 단어를 검색


검색하고 싶은 단어 위에서 위의 명령어로 검색해 보세요.

특별한 타자 없이 단어를 검색할 수 있어요.

두 명령어의 차이는 *는 단어 단위로 검색을 하고 g*는 단순히 해당 단어를 검색하게 되요.


대문자 소문자 무시


기본적으로 Vim은 검색할 때 대문자와 소문자를 구분해요.

그래서 Vim 이라는 글자를 검색하는 것과 vim 이라는 글자를 검색하는 결과가 달라지죠.

그렇지만 가끔 대소문자를 구분하지 않고 검색하고 싶을 때가 있지요.

그럴 때는 옵션을 변경하는 방법이 있는데...

사실 그건 굉장히 귀찮아요.

검색할 때마다 현재 상태가 무언지 모르니 매번 옵션 설정을 주어야 하니까요.

그냥 아래와 같이 하나만 알도록 해요.


  • /\c검색할단어


위 처럼 "/\c"를 앞에 넣고 검색할 단어를 입력하게 되면 대소문자를 무시하고 검색을 해 주죠.



그림 처럼 Vim과 vim이 한번에 검색 된 것을 볼 수 있지요.


이전에 검색 단어 찾기


검색을 하다 보면 이전에 검색했던 단어를 다시 찾아야 하는 경우가 있어요.

이럴 때 다시 검색한다고 타자을 치고 있으면 너무 힘들잖아요.

그럴 때 아래와 같은 명령어로 이전에 검색했던 단어를 찾을 수 있어요.


  • CTRL-P : 이전에 검색했던 단어 찾기
  • CTRL-N : CTRL-P로 이동한 역순으로 단어 찾기


위의 명령어는 Command-line에서도 사용할 수 있어요.

이전에 적었던 명령어를 다시 적지 않아도 되는거죠.^^


마치며....


검색 부분은 사실 다음 장에서도 다시 진행해야 할 거 같아요.

중요한 부분인 정규식 부분을 하지 않았거든요. ^^;;

그리고 검색이 나왔으니 검색과 한 쌍인 "바꾸기"도 설명을 하지 않기도 했고요.

오늘 퇴근이 늦어서 원하는 만큼 적지 못했지만, 다음 장에 마무리하도록 하겠습니다.

감사합니다.

2017년 11월 27일 월요일

Vim의 확장 기능; Key Mapping

시작하며....


오늘 주제를 정한 거는 Help였는데 정리가 잘되지 않아서 갑자기 주제를 바꾸게 되었어요.

Help는 조금 더 진행을 한 다음에 나와도 괜찮을 거 같다는 생각이 들었기 때문이죠.

Key Mapping도 굉장히 중요한 Vim의 능력 중의 하나예요.

그러니 같이 알아보아요!!


Windows에서의 Ctrl+F


지난 강좌에서 Ctrl+F의 명령어는 Page Down과 같다고 했지요.

하지만 윈도우에서 Ctrl+F를 눌렀을 때는 다른 프로그램처럼 찾기가 되는 걸 볼 수 있어요.



리눅스에서 동일하게 Ctrl+F를 눌렀다면 아마 Page Down이 되었을 거예요.

그런데 윈도우에서는 그렇지 않다니 이상하지요??

그 이유는 윈도우 vim의 설정 파일을 보시면 알 수 있어요.

"C:\Program Files (x86)\Vim\_vimrc"

위의 파일을 열면 아래와 같은 설정을 볼 수 있어요.



source는 해당 파일에서 실행 가능한 명령어를 읽어서 설정을 하는 거죠.

"$VIMRUNTIME/mswin.vim"의 위치는 아래와 같아요.

"C:\Program Files (x86)\Vim\vim80\mswin.vim" 

저 파일을 열어서 보면 아래와 같은 부분을 확인할 수 있어요.

if has("gui")
  " CTRL-F is the search dialog
  noremap <C-F> :promptfind<CR>
  inoremap <C-F> <C-\><C-O>:promptfind<CR>
  cnoremap <C-F> <C-\><C-C>:promptfind<CR>

  " CTRL-H is the replace dialog
  noremap <C-H> :promptrepl<CR>
  inoremap <C-H> <C-\><C-O>:promptrepl<CR>
  cnoremap <C-H> <C-\><C-C>:promptrepl<CR>
endif


if문에서 gui라는 Feature를 가졌느냐고 물어보네요.

가졌을 때 noremap, inoremap, cnoremap 라는 명령어가 수행된다라고 볼 수 있지요.

우선 저 명령어가 무엇인지 알아보기 전에 기본형을 알려 드릴게요.

map KEY 명령어_or_KEY

대충 저 정도가 형식으로 보면 되고요.

KEY명령어나 다른 Key로 Mapping 된다고 보시면 쉬울 거 같아요.

저 map 명령어는 크게 2가지로 구분할 수 있지죠.


  • map의 적용 모드 별
  • map의 용도 별


이 구분 방법으로 각각 자세하게 볼게요.


map의 적용 모드 별 구분


Vim의 가장 기초가 모드가 나누어져 있다는 거죠?

Mapping을 할 때에도 그때 그때 필요한 모드가 나누어져야 해요.

예를 들어 Normal 모드에서만 Mapping을 하고 싶을 때가 있을 텐데 Visual Mode 일 때도 Mapping이 되어 있으면 곤란하잖아요.

그래서 적용 모드 별로 map의 명령어가 조금씩 달라져요.


  • map : Normal, Visual, Select, Operator-pending
  • nmap : Normal
  • vmap : Visual and Select
  • xmap : Visual
  • smap : Select
  • omap : Operator-pending
  • map! : Insert and Command-line
  • imap : Insert
  • lmap : Insert, Command-line, Lang-Arg
  • cmap : Command-line


사실 막~ 외울 필요는 없어요.

:help map-overview

위의 명령어를 적으면 map에 대한 모드별 정보를 언제든 알 수 있어요.

그러니 help 명령어만 아시면 특별히 외울 필요 없다는 거죠.

그리고 map이라는 명령어를 기본으로 Prefix나 Postfix가 붙어 있는 형태이고 해당 문자들이 모드의 이름과 비슷한 점이 많아서 어렵지는 않을 거예요.


map의 용도 별 구분


용도 별로 아래와 같이 3가지로 나눌 수 있지요.


  • Key Mapping : map KEY 명령어_or_KEY, noremap KEY 명령어_or_KEY
  • Key Mapping 삭제 : unmap KEY, mapclear
  • Key Mapping 출력 : map, map KEY


위의 명령어는 가장 기본이 되는 명령어를 적은 거예요.

저 명령어에 모드별로 나누었을 때의 Prefix나 Postfix를 적어 주면 모든 map 명령어가 나오게 되지요.

물론 help 명령어로 찾아볼 수 있으니 무조건적인 암기보다는 help 사용법에 더 익숙해 지시는 게 좋을거 같아요.

사실 여기서 알아봐야 하는 건 map과 noremap의 차이가 더 중요한 거 같아요.


map과 noremap


map은 recursive mapping이고 noremap은 non-recursive mapping이라고 하네요.

recursive라는 의미가 순환인데 순환을 하면서 mapping이 된다는 의미로 보면 될 거 같아요.

map d y
map j d
noremap k d

위의 예를 가지고 이야기를 해 드릴게요.

처음 map을 보니 Key d를 Key y에 Mapping을 했어요.
( d -> y(복사) )

그러니 d를 눌렀을 때 y가 입력된 효과가 일어나게 되죠.

즉, 삭제하려고 했더니 복사가 되는 거죠.

그리고 두 번째 map을 보니 Key j가 Key d에 Mapping이 된다고 나오네요.
( j -> d )

그럼 여기까지 했을 때 Key j를 누르면 Mapping된 d의 본래 기능인 삭제가 될까요?

아니에요.

recursive라는 거처럼 d가 Mapping된 y까지 연결되어요.
( j -> d -> y(복사) )

그러니 j를 누르면 d가 불리고 d와 연결된 y가 최종적으로 불리게 되는 거죠.

하지만 noremap은 map과는 달라요.

recursive를 하지 않기 때문에 k를 눌렀을 때 Mapping된 d의 본래 기능인 삭제가 호출되는 거죠.
( k -> d(삭제) )

그러니 recursive를 하면 Mapping이 되지 않은 마지막까지 찾아가서 해당 명령어의 기능을 자신이 가지는 거라고 생각하면 될 거 같아요.

그럼 여기서 하나 질문...

위의 map 설정을 하고 아래와 같은 명령어를 입력하면 어떻게 될까요??

map y j

즉, y -> j -> d -> y 식이 되는 거겠죠??

일단 map 명령어는 문제없이 진행되는데 y, j, d 중의 하나의 명령어를 입력하면 아래와 같은 재귀맵핑 이라는 에러가 나올 거예요.



다시 Windows의 Ctrl+F


그럼 윈도우의 설정 파일에 적혀 있던 noremap, inoremap, cnoremap에 대해서 다시 볼까요???

<C-F>에 대해 적혀 있던 내용은 아래와 같아요.

noremap <C-F> :promptfind<CR>
inoremap <C-F> <C-\><C-O>:promptfind<CR>
cnoremap <C-F> <C-\><C-C>:promptfind<CR>

처음 명령어를 읽어 보면 Normal, Visual, Select, Operator-pending 상태에서 non-recursive로 Mapping을 하는데 Ctrl+F(<C-F>)는 :promptfind와 엔터(<CR>)이네요.

그러니 Ctrl+F를 눌러도 찾기가 나오는 거예요.

두 번째와 세 번째의 명령어는 각각 Insert Mode와 Command-line Mode에서의 Mapping이고요.

<C-\><C-O>는 Insert Mode에서 ESC를 누르면 커서가 한칸 앞으로 이동 하는 문제를 해결 한 후에 Command-line을 진입하기 위한 준비 작업입니다.

또한 <C-\><C-C>는 Command-line을 빠져 나가는 명령어 이고요.


Windows에서 Ctrl+F를 Page Down으로 사용하기


위의 내용이 길었지만 이걸 하는 방법에 대해서는 쉽게 알 수 있겠지요???

적용된 Mapping Rule을 삭제 하면 되요.

그건 unmap 명령어를 사용하면 되겠지요?

물론 Insert와 Command-line Mode에서도 모두 삭제 하도록 해야 하고요.

그럼 다음과 같은 명령어 셋이 나오겠지요??

unmap <C-F>
iunmap <C-F>
cunmap <C-F>


마치며....


실제로 예제를 든건 Ctrl+F에 Mapping된 명령어를 제거하는거 였지만...

그걸 위해 Mapping에 대한 전반적인 내용은 보았습니다.

사실 실전이 가장 중요한데...

이 Mapping은 나중에도 엄청 나오니까 그때 다시 보면서 연습을 하도록 할게요.

그럼 또 다음에 뵙겠습니다.

감사합니다.





수상한 흥신소 연극 관람




오늘은 오랜만에 연극을 보러 갔다 왔네요.^^

거진 5~6년 만인거 같아요.

연애 할 때는 극장도 자주 가고 했었는데 결혼 후에는 극장이나 연극은 잘 안가게 되더라고요.

그래도 기회가 생겨서 어머니를 모시고 다녀 왔는데..

좋은 연극을 잘 본거 같아요~

웃길 때는 웃겨주고 울릴 때는 울게 해주고..

이상하게 저는 엄마, 부인을 주제로 슬픈 이야기만 나오면 눈물이 나더라고요.

엄마도 와이프도 잘 봤다고 하니 왠지 뿌듯 하더라고요.ㅎㅎ

다음에는 어떤걸 또 볼지...^^

12월에도 재미있는거 찾아서 보러 가야겠어요~

모두 기회 되면 수상한 흥신소 보세요~


2017년 11월 24일 금요일

왕게임 - 카나자와 노부아키



시작하며....


두 번째 책부터 만화라니..ㅎㅎ

핑계라고 하면 핑계인데 이북이라는 걸 구입 했습니다.

7.8인치의 보위에 라이크 북을 샀지요.

6인치는 만화책 보기에는 너무 화면이 작다는 것을 알기 때문에 7.8인치를 구매했어요.

그리고 실제 만화책을 보기에는 어떤지 본 거입니다.

결코 주당 독서의 양을 채우려고 한 건 아니에요.^^;;;

아참.. 이 감상문에는 스포일러가 있습니다.


왕게임


왕게임이라는 말을 들으면 사실 대부분 남자들은 부끄부끄한 생각이 들지 않나요??

미팅 같은 곳에서 술을 마시면 하는 게임 중 하나지요.

게임 중 한 명이 왕이 되어 나머지 인원들에게 아무거나 시키는 거죠.

처음에는 간단한 벌칙이 나오지만, 후반부가 되면 야릇한 걸 하곤 하죠.

저도 별로 못 해 봐서 어디까지 가능한지는 잘 모릅니다!!! ㅎㅎ;;

어찌되었든 만화책에서의 제목처럼 이 역시 왕이 지시한 모든 명령을 지켜야 합니다.

당일 왕의 명령을 어기게 되면 큰 벌칙을 받게 됩니다.

그것이 죽음으로 이어지기까지 하죠.


잔인성, 선정성


일본 만화에서나 가능한 선정성과 잔인성 모두 가지고 있습니다.

초반에는 간단한 명령이었지만 왕의 명령은 점점 선정성으로 넘어가죠.

A양와 B군은 잠자리를 가져라.

하지만 A양은 이미 남자친구가 있고 A양의 남친은 B군에게 끔찍한 짓을 하게 되죠.

그렇게 명령이 나날이 내려질수록 반의 학생들은 하나씩 죽게 되는데...

그 죽는 장면이 굉장히 사실적으로 잔인하게 그려져요.

그런 점에 거부감을 가지신 분들에게는 추천하고 싶지 않네요.


왕은 누구인가??


책을 읽는 중에 가장 궁금한 것은 도대체 왕은 누구인가죠.

누군데 간단한 명령만으로 사람을 죽게 하는 건지...

책의 주인공들도 왕을 찾고 왕의 명령으로부터 자유로워지려고 하죠.

하지만 결말에 다가가면서 밝혀지는 왕에 대해서 많이 실망을 하신 거 같아요.

작가가 처음부터 왕에 대해 생각하고 글을 쓴 것인지는 모르겠지만...

저에게는 나쁘지는 않았어요.

어차피 읽다 보면 보이지 않는 존재일 것이라는 생각을 했을 텐데...

그 때 귀신 같은 영적 존재였어도 누군가는 반드시 실망감을 느꼈을 테니까요.
(음.. 어쩌면 영적인 존재 일 수 있겠네요..;;;)

왕을 찾기 위해 다가가는 방식 자체는 다른 일본 영화나 책에서의 방식과 큰 차이가 없었어요.

링이라는 영화에서도 자꾸 살인 사건이 나오니 귀신이 나온 근원을 찾으러 가고 원인을 해결하려고 하잖아요.

제 입장에서는 그 흐름이 거의 비슷했던 거 같아요.

네이버에 검색해 보니 여러 외전이 나왔는데 다른 책에서는 어떻게 다가갈지 궁금하네요.


마치며....


물론 왕의 정체를 알고 나서의 허탈감을 받은 분들도 많았을 텐데 그래도 신선한 소재였다고 생각해요.

만화적인 요소로 과장 되긴 했지만 고장 난 냉동칸에 갇힌 사람이 얼어 죽은 이야기처럼 마음만 먹으면 어느 정도는 가능하다고 볼 수 있지 않을까요?

최근의 광고에는 마음을 준다는 게 모두 준다거나 마음을 먹으면 무엇이든 할 수 있다고 하기도 하고요.

그렇게 끼어 맞춘다면 작가의 결론도 나쁘지 않았던 거 같았습니다.

지금도 열심히 읽고 있는 책이 있으니 다음 주에는 다른 책으로 찾아뵙겠습니다.

감사합니다.