GNUEmacsManual:G

Emacs와 Microsoft Windows/MS-DOS(Emacs and Microsoft Windows/MS-DOS)

이번 절에서는 Microsoft Windows에서 Emacs를 사용할 때 특징에 대해 설명하고자 한다. 이러한 특징 중 일부는 Microsoft의 오래된 MS-DOS "운영체제"("MS-DOG"로도 알려짐)와 관련이 있다. 하지만 MS-DOS에만 관련된 Emacs 기능은 별도의 매뉴얼에서 설명한다(Specialized Emacs Features의 "MS-DOS"절 참고).

MS-DOS에서 Emacs의 동작은 긴 파일명, 다중 프레임, 스크롤 바, 마우스 메뉴, 하위프로세스의 지원을 포함해 매뉴얼 나머지 부분에 설명된 내용과 상당히 유사하다. 하지만 몇 가지 특별하게 적용되는 사항을 아래에서 설명하겠다.

MS-Windows에서 Emacs를 시작하는 방법(How to Start Emacs on MS-Windows)

MS-Windows에서 Emacs를 시작하는 방법에는 여러 가지가 있다.

1. 데스크톱 바로가기 아이콘을 사용한다. 아이콘을 왼쪽 마우스 버튼으로 더블 클릭하거나 한 번 클릭한 후 RET 를 입력한다. 데스크톱 바로가기 아이콘에는
   emacs.exe
   가 아니라
   runemacs.exe
   의 전체 절대 파일명을 "Target"(바로가기 "Properties"에 표시)으로 명시한다. 그 이유는 바로가기 대상(target)이
   emacs.exe
   일 경우 (Windows에 관한 한 이것은 콘솔 프로그램이다) 생성되는 콘솔 창을
   runemacs.exe
   가 숨기기 때문이다. 이 방법을 사용 시 Emacs는 바로가기에서 명시한 디렉터리에서 시작한다. 디렉터리 위치를 변경하려면 바로가기 아이콘을 오른쪽 마우스로 클릭하고 "Properties"를 선택한 다음 "Shortcut" 탭에서 "Start in" 필드를 원하는 대로 수정한다.
2. Command Prompt 창에서 프롬프트에
   emacs
   RET 를 입력한다. 이를 실행한 Command Prompt 창은 이제 Emacs가 끝날 때까지 다른 명령어를 호출하는 데에 이용할 수 없다. 이런 경우 Emacs는 Windows 셸의 현재 디렉터리에서 시작할 것이다.
3. Command Prompt 창에서 프롬프트에
   runemacs
   RET 를 입력한다. 이를 실행한 Command Prompt 창은 즉시 다른 명령어를 호출하는 데에 이용 가능하다. 이런 경우 Emacs는 Windows 셸의 현재 디렉터리에서 시작할 것이다.
4. 다른 프로그램으로부터 Emacs 를 호출하고 다른 프로그램에서 필요로 하는 편집 작업을 수행하기 위해 실행 중인 Emacs 프로세스를 재사용할 수 있게 해주는
   emacsclient.exe
   또는
   emacsclientw.exe
   를 사용한다. 393 페이지의 31.5절 [Emacs 서버(Emacs Server)]를 참고한다.
   emacsclient.exe
   와
   emacsclientw.exe
   의 차이는, 전자는 콘솔 프로그램이고 후자는 Windows GUI 프로그램이라는 데에 있다. 두 프로그램 모두 Emacs 를 끝내고 그것을 호출한 프로그램으로 제어를 돌려주기 전에 Emacs가 편집 중인 작업이 완료되었음을 신호로 보낼 때까지 기다린다. 둘 중 무엇을 언제 사용하는지는 편집 서비스를 필요로 하는 프로그램의 기대치에 따라 좌우된다. 해당 프로그램 자체가 콘솔(text-mode) 프로그램일 경우
   emacsclient.exe
   를 사용해야만 그 메시지와 프롬프트들이 호출(invoking) 프로그램의 것과 동일한 명령창(command window)에 나타난다. 반면 호출 프로그램이 GUI 프로그램이라면
   emacsclientw.exe
   를 사용하는 편이 나은데,
   emacsclient.exe
   는 GUI 프로그램으로부터 호출될 경우 명령창을 팝업할 것이기 때문이다. Windows Explorer 에서 파일에 오른쪽 마우스로 클릭하여 팝업 메뉴에서 "Open With"를 선택할 때는
   emacsclientw.exe
   를 사용하길 원할 것이다.
   emacsclient
   가 호출될 때 Emacs가 실행 중이지 않을 경우 (또는 서버로서 실행 중이지 않을 경우) '
   --alternate-editor=
   ' 또는 '
   -a
   ' 옵션을 사용하면 항상 에디터를 제공해줄 것이다.
   emacsclient
   를 통해 호출 할때 Emacs 는
   emacsclient
   를 호출한 프로그램의 현재 디렉터리에서 시작할 것이다.

주의할것이 있는데, MS-Windows의 한계로 인해 Emacs는 동일한 세션에서 GUI와 텍스트 모드(text-mode) 프레임을 모두 가질 수 없다. 어느 시점에서든 Windows 프로그램마다 하나의 콘솔만 가질 수 있기 때문에 하나보다 많은 Command Prompt 창에서 텍스트 모드 프레임을 열 수도 없다. 이러한 이유로

-c

옵션을 이용해

emacsclient

를 호출하고 Emacs 서버가 텍스트 모드 세션에서 실행되면 Emacs는 그것이 시작된 것과 동일한 Command Prompt 창에서 새로운 텍스트 모드 프레임을 생성할 것이고, 서버가 GUI 세션에서 실행될 때에만 GUI 프레임이 생성될 것이다. 마찬가지로

-t

옵션으로

emacsclient

를 호출하면 Emacs는 서버가 GUI 세션에서 실행될 경우 GUI 프레임을 생성하고, 세션이 Command Prompt 창의 텍스트 모드에서 실행되면 텍스트 모드 프레임을 생성할 것이다. 395 페이지의 31.5.2절 [emacsclient 옵션(emacsclient Options)]을 참고한다.

텍스트 파일과 이진 파일(Text Files and Binary Files)

GNU Emacs 는 텍스트 라인을 구분할 때 개행 문자를 사용한다. 이것은 GNU, Unix, 그 외 Posix-compliant 시스템을 기반으로 한 규칙이다. 반면 MS-DOS 와 MS-Windows 는 보통 2개 문자로 된 시퀀스, carriage-return linefeed 를 이용해 텍스트 라인을 구분한다. (Linefeed는 개행 문자와 동일한 문자다.) 따라서 Emacs를 이용한 일반 파일의 편리한 편집을 위해서는 이러한 행끝(EOL) 시퀀스의 규칙을 필요로 한다. 그리고 이는 Emacs 가 주로 실행하는 동작으로, 파일을 읽을 때 carriage-return linefeed를 개행 문자로 변환하고, 파일을 쓸 때는 개행 문자를 carriage-return linefeed 로 변환한다. 국제 문자 코드의 변환을 처리하는 메커니즘도 이러한 변환을 실행한다(183 페이지의 19.5절 [코딩 시스템(Coding Systems)] 참고).

대부분 파일에 대해 이렇게 특수 포맷 변환을 실행할 경우, Emacs가 보고한 문자 위치가 (22 페이지의 4.9절 [위치 정보(Position Info)] 참고) 운영체제에 알려진 파일 크기 정보와 일치하지 않는 결과를 야기하곤 한다.

또한 Emacs가 파일 내용으로부터 carriage-return linefeed 대신 개행 문자를 라인 구분 문자가 사용된다는 사실을 인식할 경우 해당 파일을 읽거나 쓸 때 EOL 규칙을 실행하지 않는다. 따라서 MS-DOS에서는 특별한 수고를 들이지 않고GNU 및 Unix 시스템으로부터 파일을 읽고 편집할 수 있으며, 그러한 파일들은 편집이 완료되면 Unix 스타일의 행끝 규칙을 유지할 것이다.

모드 라인은 행끝 해석이 현재 버퍼에 사용되었는지를 나타낸다. MS-DOS 행끝 해석이 버퍼에서 사용 중일 경우 Emacs의 MS-Windows 빌드는 모드 라인 시작 부근에 코딩 시스템 연상 기호 뒤에 백슬래시 '\'를 표시한다(8 페이지의 1.3절 [모드 라인(Mode Line)] 참고). 어떠한 EOL 해석도 실행되지 않았다면 백슬래시 대신 '(Unix)' 문자열이 표시되어 파일의 EOL 포맷이 일반 carriage-return linefeed가 아님을 경고한다.

파일을 방문하여 DOS 스타일과 Unix 스타일의 행끝 규칙 중에서 무엇을 사용하는지 명시하고 싶다면 코딩 시스템을 명시하라(188 페이지의 19.9절 [텍스트 코딩(Text Coding)] 참고). 가령 C-x RET c unix RET C-x C-f foobar.txt 는 EOL을 변환하지 않고

foobar.txt

파일을 방문하는데, 몇몇 라인이 carriage-return linefeed 쌍으로 끝나는 경우 Emacs가 해당 라인의 끝에 '

^M

'을 표시할 것이다. 이와 비슷하게 C-x RET f 명령어를 이용하면 명시된 EOL 포맷으로 버퍼를 저장하도록 Emacs에게 지시할 수 있다. 예를 들어, Unix EOL 포맷으로 된 버퍼를 저장하려면 C-x RET f unix RET C-x C-s 를 입력한다. DOS EOL 변환으로 된 파일을 방문할 경우 Unix EOL 포맷으로 저장하면 파일을

dos2unix

프로그램처럼 효과적으로 Unix EOL 스타일로 변환한다.

GNU 또는 Unix 시스템을 이용하는 컴퓨터에 상주하는 파일 시스템으로 접근할 때 NFS, Samba, 또는 그와 비슷한 방법을 사용할 경우 Emacs는 이러한 파일 시스템에 있는 어떠한 파일에도 행끝 해석을 실행해선 안 되며, 심지어 새 파일을 생성할 때에도 마찬가지다. 이를 요청하려면

add-untranslated-filesystem

함수를 호출하여 이러한 파일 시스템을 해석되지 않은(untranslated) 파일 시스템으로 지정하라. 이는 하나의 인자를 취하는데, 바로 드라이브 문자와 선택적 디렉터리를 포함하는 파일 시스템명이다. 예를 들어,

(add-untranslated-filesystem "Z:")

위는 드라이브 Z를 해석되지 않은 파일 시스템으로 지정하고,

(add-untranslated-filesystem "Z:\\foo")

위는 드라이브

Z

에서

\foo

디렉터리를 해석되지 않은 파일 시스템으로 지정한다.

대부분의 경우

.emacs

파일 또는

site-start.el

에서

add-untranslated-filesystem

을 사용하면 당신의 지역(site)에 위치한 모든 사용자에게 유익할 것이다.

add-untranslated-filesystem

의 효과를 취소하려면

remove-untranslated-filesystem

함수를 사용하라. 이 함수는 하나의 인자를 취하는데, 이는

add-untranslated-filesystem

으로 이전에 사용한 것과 마찬가지로 문자열에 해당한다.

해석되지 않은 파일 시스템으로 지정하게 되면 문자 집합 규칙에는 영향을 미치지 않으며 행끝 규칙에만 영향을 미친다. 기본적으로 이는 행끝에서 개행 문자를 이용하는 Unix 스타일의 규칙으로 새 파일을 생성할 것을 Emacs 에게 지시하는 것이다. 183 페이지의 19.5절 [코딩 시스템(Coding Systems)]을 참고한다.

MS-Windows에서 파일명

MS-Windows 와 MS-DOS 는 다른 시스템에서 사용하는 슬래시 대신 파일명에서 이름 단위를 구분하기 위해 백슬래시 '

\

' 를 이용한다. MS-DOS/MS-Windows에서 Emacs는 슬래시와 백슬래시의 사용을 모두 허용하고, 파일명에 포함된 드라이브 문자도 인식한다.

MS-DOS/MS-Windows 에서 파일명은 대, 소문자에 민감하므로 Emacs는 완성 중에 파일명에서 대, 소문자를 무시하는 것을 기본값으로 한다.

w32-get-true-file-attributes

변수는 Emacs 가

file-attributes

나

directory-files-and-attributes

와 같은 기본형 변수(primitives)에서 파일 속성을 좀 더 정확하게 결정하기 위해 추가 시스템 호출을 발행시켜야 하는지를 정한다. 이러한 추가 호출은 올바른 파일 소유권, 링크 계수(link count), pipes와 같은 특수 파일에 대한 파일 유형을 보고하는 데에 필요하다. 이러한 시스템 호출이 없다면 파일 소유권은 현재 사용자로 돌아가고, 링크 계수는 항상 1로 보고될 것이며, 특수 파일은 일반 파일로 보고될 것이다.

이 변수의 값이

local

(기본값)일 경우 Emacs는 로컬로 고정된 드라이브의 파일에만 이러한 추가 시스템 호출을 발행할 것이다. 그 외

nil

을 제외한 값은 제거 가능하고 원격의 volume 에도 이를 실행함을 의미하므로, Dired와 다른 관련 기능의 속도를 늦출 가능성이 있다. nil 값은 그러한 시스템 호출을 절대 발생(issue)시키지 않음을 의미한다. nil을 제외한 값은 FAT, FAT32, exFAT volumes보다는 하드 링크와 파일 보안(file security)을 지원하는 NTFS volume 에서 더 유용하다.

Unix와 달리 MS-Windows 파일 시스템은 파일명에서 사용할 수 있는 문자 집합을 제한한다. 제한되는 문자를 아래에 싣겠다.

• Shell 방향재지정(redirection) 심볼 '
  <
  ', '
  >
  ', '
  |
  '.
• 콜론 '
  :
  ' (드라이브 문자 뒤의 콜론은 예외).
• 순방향 슬래시 '
  /
  ' 와 역슬래시 '
  \
  ' (디렉터리 구분 문자는 예외).
• 와일드카드 문자 '
  *
  '와 '
  ?
  '.
• 코드포인트가 1부터 31까지 10진수에 해당하는 제어 문자. 특히 파일명에서 개행 문자는 허용되지 않는다.
• 코드포인트가 0인 null 문자 (이 제약은 Unix filesystem에서도 존재한다.)

또한 이름이 파일명 확장자의 유무와 상관없이 DOS 문자 장치에 일치하는 파일의 참조(예:

NUL

,

LPT1

,

PRN

,

CON

)는 어떤 디렉터리에서든 그러한 문자 장치로 바뀔(resolve to) 것이다. 따라서 그러한 파일명은 해당하는 문자 장치를 사용하고자 할 때만 사용하라.

MS-Windows에서 ls의 에뮬레이션(Emulation of ls on MS-Windows)

Dired는 보통 Dired 버퍼에 열거된 디렉터리 리스팅을 생성하기 위해 외부 프로그램

ls

를 사용한다(315 페이지의 27장 [Dired] 참고). MS-Windows 와 MS-DOS 시스템에서 GNU

ls

의 포트 몇 개는 이용할 수 있지만

ls

프로그램은 포함되어 있지 않다. 따라서 이러한 시스템에서는 Emacs 가

ls-lisp.el

패키지를 이용하여 Lisp 에서

ls

를 에뮬레이트한다.

ls-lisp.el

은

ls

의 전반적인 에뮬레이션을 제공하는 반면 해당 에뮬레이션에 특정적인 기능과 옵션들도 존재하는데, 상세한 내용은

ls-lisp

으로 시작하는 이름의 변수를 다룬 문서를 참고한다.

MS-Windows에서 HOME 그리고 시작 디렉터리(HOME and Startup Directories on MS-Windows)

Windows 에서

HOME

은 사용자 특정적 애플리케이션 데이터 디렉터리(user-specific application data direc­tory)에 해당한다. 실제 위치는 Windows 버전에 따라 좌우되며, 일반적인 값은 Windows 2000/XP/2K3 에서는

C:\DocumentsandSettings\username\ApplicationData

, Windows Vista/7/2008 에서는

C:\Users\username\AppData\Roaming

, 그리고 Windows 9/ME 에서는

C:\WINDOWS\Application Data

또는

C:\WINDOWS\Profiles\username\Application Data

에 위치한다. 이 디렉터리가 존재하지 않거나 접근할 수 없을 경우 Emacs 는

C:\

를

HOME

의 기본값으로 사용한다.

HOME

의 기본값은

HOME

환경 변수를 시스템의 디렉터리로 직접 지시하여 오버라이드할 수 있다.

HOME

은 '

My Computer

' 의 '

Properties

' 대화창이나 명령 셸 프롬프트에서 설정할 수 있다.

HOME

은 시스템 레지스트리에서도 설정 가능하며, 관련 내용은 486 페이지의 C.4.3 절 [MS-Windows Registry]를 참고한다.

Emacs의 기존 버전과 호환을 위해 드라이브 C: 의 루트 디렉터리

C:\

에

.emacs

라는 파일이 있고

HOME

이 환경이나 Registry 에서 모두 설정되지 않은 경우, Emacs 는

C:\

를 기본

HOME

위치로 취급하고 애플리케이션 데이터 디렉터리가 있다 하더라도 그곳은 검색하지 않을 것이다.

C:\

에서는

.emacs

만 검색할 것이며, 오래된 이름인

_emacs

(아래 참고)는 검색하지 않는다.

HOME

을 저장하기 위해

C:\.emacs

를 사용하던 규칙은 사라졌다.

최종 위치가 어디든 Emacs 는

HOME

환경 변수의 내부 값은 그것을 가리키도록 설정하고, 그것이 일반적으로 검색하거나 홈 디렉터리에서 생성하는 디렉터리 및 기타 파일로서 그 위치를 사용할 것이다.

C-x d ~ / RET 를 입력하면 Emacs 가 생각하는 사용자 홈 디렉터리의 위치를 알아낼 수 있다. 이는 홈 디렉터리 내 파일의 목록을 표시하고, 그 전체 이름을 첫 라인에 표시할 것이다. 마찬가지로 init 파일을 방문하려면 C-x C-f ~/.emacs RET 를 입력하라(파일명이

.emacs

라고 가정하여).

홈 디렉터리는 사용자의 init 파일이 보관되는 장소다. 이는 437 페이지의 33.4절 [Init 파일(Init File)]에 언급된 이름을 가질 수 있다.

MS-DOS는 점으로 시작하는(leading dot) 파일명은 허용하지 않는데다가 오래된 Windows 시스템에서는 그러한 이름으로 된 파일을 생성하는 것이 매우 힘들기 때문에 홈 디렉터리에

_emacs

란 init 파일이 존재하고

.emacs

란 파일은 존재하지 않을 경우 Emacs 의 Windows 포트는

_emacs

를 지원한다. 이 이름은 구식으로 간주된다.

MS-Windows에서 키보드 사용(Keyboard Usage on MS-Windows)

이번 절에서는 Emacs에서 키보드 입력과 관련된 Windows 특정적 기능을 설명한다.

MS-Windows 프로그램에서 전형적으로 사용되는 많은 키 조합들은 ("키보드 단축키(keyboard shortcuts)"로도 알려짐) 전통적인 Emacs 키 바인딩과 상충된다. (이러한 Emacs 키 바인딩은 Microsoft사가 설립되기 수 년 전에 구축되었다.) 상충되는 키의 예로, C-c, C-x, C-z, C-a, W-SPC 를 들 수 있다. 이들 중 몇몇은 CUA Mode를 활성화하여 MS-Windows에 알맞는 의미로 재정의할 수 있다(62 페이지의 9.6절 [CUA 바인딩(CUA Bindings)] 참고).

이 범주에서 추가로 Windows 특정적 변수에 관한 정보는 Info 파일

emacs

, 노드(node) '

Windows Keyboard

' 를 참고한다.

w32-apps-modifier

변수는 Apps 키의 효과를 제어한다(주로 오른쪽 Alt 키와 오른쪽 Ctrl 키 사이에 위치). 그 값은 각 수식키마다

hyper

,

super

,

meta

,

alt

,

control

,

shift

중 하나이거나 apps 키로 표시되는

nil

이 될 수 있다. 기본값은

nil

이다.

w32-lwindow-modifier

변수는 좌측 Windows 키의 효과를 결정한다(주로

start

라는 라벨과 Windows 로고가 표시되어 있다). 그 값이

nil

(기본값)이면 키는

lwindow

심볼을 생성할 것이다. 그 값을

hyper

,

super

,

meta

,

alt

,

control

,

shift

중 하나로 설정하면 그에 해당하는 수식키를 생성할 것이다. 비슷한 변수인

w32-rwindow-modifier

는 오른쪽 Windows 키의 효과를 제어하고,

w32-scroll-lock-modifier

는 ScrLock 키에 대한 효과를 제어한다. 이러한 변수들이

nil

로 설정되면 오른쪽 Windows 키는

rwindow

심볼을 생성하고 ScrLock 은

scroll

심볼을 생성한다.

Native Windows 애플리케이션으로 컴파일된 Emacs 는 보통 Alt 키를 누르면 Windows 메뉴를 호출하는 Windows 기능을 꺼놓는다. 그 이유는 Alt 가 Emacs 에서 META 의 역할을 하기 때문이다. 사용자들은 Emacs를 사용할 때 META 키를 누르고 나서 마음이 바뀌곤 하는데, META 키를 눌렀을 때 Windows 메뉴를 가져오는 효과가 있다면 잇따른 명령어의 의미가 수정된다. 이에 많은 사용자들이 당황하기도 한다.

w32-pass-alt-to-system

을

nil

이 아닌 값으로 설정함으로써 Alt 키의 누름 행동에 대한 Windows의 기본 처리를 다시 켤 수 있다.

MS-Windows에서 마우스 사용(Mouse Usage on MS-Windows)

이번 절에서는 마우스와 관련된 Windows 특정적 변수를 설명한다.

w32-mouse-button-tolerance

변수는 버튼이 2개인 마우스에서 중간 마우스 버튼이 있는 것으로 가장하는 시간 간격을 밀리 초로 명시한다. 이 시간 간격 이내에 마우스 버튼 두 개를 누르면 Emacs 는 버튼 중 하나를 더블 클릭하는 대신 중간 마우스 버튼 클릭 이벤트를 발생시킨다.

w32-pass-extra-mouse-buttons-to-system

변수가

nil

이 아닌 값일 경우 Emacs는 네 번째와 다섯 번째 마우스 버튼을 Windows로 전달한다.

w32-swap-mouse-buttons

변수는 3개의 마우스 버튼 중에서 무엇이 mouse-2 이벤트를 생성하는지를 제어한다. 값이 nil(기본값)인 경우 중간 버튼이 mouse-2 를 발생시키고 오른쪽 버튼이 mouse-3 이벤트를 발생시킨다. 변수 값이

nil

이외의 값일 경우 2개 버튼의 역할은 바뀐다.

Windows 9X/ME와 Windows NT/2K/XP에서 하위프로세스(Subprocesses on Windows 9X/ME and Windows NT/2K/XP)

(DOS 버전과 상반되는) Native Windows 애플리케이션으로 컴파일된 Emacs는 비동기식 하위프로세스를 전적으로 지원한다. Windows 버전에서 동기 및 비동기 하위프로세스는 32-bit Windows 애플리케이션의 실행으로만 제한하는 한 Windows 9X/ME와 Windows NT/2K/XP에서 완벽하게 작동한다. 하지만 하위프로세스에서 DOS 애플리케이션을 실행하면 문제에 직면하거나 애플리케이션을 전혀 실행할 수 없게 되고, 두 개의 하위프로세스에서 동시에 두 개의 DOS 애플리케이션을 실행하면 시스템을 재부팅해야 할지도 모른다.

Windows 9X에서 표준 명령어 해석기(그리고 대부분의 명령행 유틸리티)는 DOS 애플리케이션이므로 그 시스템을 사용 시 이러한 문제들은 커진다. 하지만 우리가 할 수 있는 일은 없으며, Microsoft사만이 문제를 수정할 수 있다.

하나의 DOS 애플리케이션 하위프로세스만 실행한다면 하위프로세스는 "잘 동작(well-behaved)"하는 한 예상대로 작동할 것이고, 직접 화면 접근이나 다른 예상치 못한 동작을 실행하지 않을 것이다. CPU 모니터 애플리케이션을 갖고 있다면 DOS 애플리케이션이 idle 상태일 때에도 사용자의 머신이 100% 다른 용무(busy)중인 것으로 나타나지만 이는 CPU 모니터가 프로세서 부하를 측정하는 방법에서 발생하는 결과일 뿐이다.

DOS 애플리케이션은 다른 하위프로세스에서 다른 DOS 애플리케이션을 시작하기 전에 종료해야만 한다. Emacs는 DOS 하위프로세스를 방해하거나 종료할 수 없다. 그러한 하위프로세스를 종료하는 유일한 방법은 그 프로그램에게 종료할 것을 알리는 명령어를 제공하는 것이다.

구분된 하위프로세스에서 동시에 두 개의 DOS 애플리케이션의 실행을 시도하면 두 번째로 시작된 하위프로세스는 첫 번째 프로세스가 끝날 때까지 보류(suspended)될 것이며, 둘 중 하나 또는 모두가 비동기식 하위프로세스라 하더라도 마찬가지다.

첫 번째 하위프로세스로 이동이 가능하여 종료할 것을 알린다면 두 번째 하위프로세스는 정상적으로 계속될 것이다. 하지만 두 번째 하위프로세스가 동기식일 경우 Emacs 자체는 첫 번째 하위프로세스가 끝날 때까지 hung 상태로 있을 것이다. 사용자의 입력 없이는 끝나지 않을 경우, Windows 9X에서 실행 중이라면 시스템을 재부팅을 하는 방법 밖에 없다. Windows NT/2K/XP에서 실행 중이라면 프로세스 뷰어 애플리케이션을 이용해 NTVDM의 적절한 인스턴스를 대신 제거할 수 있다(그러면 DOS 하위프로세스 두 개가 모두 종료될 것이다).

이러한 상황에서 Windows 9X 를 재부팅해야 한다면

Start

메뉴에서

Shutdown

명령어를 사용하지 말라. 이를 사용하면 시스템을 hung 상태로 만들 것이다. 대신 Ctrl-Alt-DEL 을 입력하고

Shutdown

을 선택하라. 몇 분이 소요될진 몰라도 효과를 있을 것이다.

w32-quote-process-args

변수는 Emacs가 프로세스 인자를 어떻게 인용하는지를 제어한다. Nil 이외의 값은 인자를 " 문자로 인용할 것을 의미한다. 값이 문자일 경우 Emacs는 그 문자를 이용해 눈에 보이는 어떠한 인용 문자도 escape하며, 문자 이외의 값을 가진 경우 프로그램 타입을 바탕으로 적절한 escape 문자를 선택한다.

출력하기와 MS-Windows(Printing and MS-Windows)

lpr-buffer

(397 페이지의 31.6절 [출력하기(Printing)] 참고)와

ps-print-buffer

(398 페이지의 31.6.1절 [PostScript] 참고)를 비롯한 출력 명령어들은 Posix-style

lpr

프로그램을 이용할 수 없는 경우 MS-DOS와 MS-Windows 에서 프린터 포트들 중 하나로 출력을 전송함으로써 작동한다. 모든 시스템에서 동일한 Emacs 변수들이 출력을 제어하지만 어떤 경우는 MS-DOS 와 MS-Windows 에 대해 서로 다른 기본값을 가진다.

MS Windows 에서 Emacs는 기본 프린터를 자동으로 결정하려 한다(

default-printer-name

함수를 이용해). 하지만 일부 드문 사례에서는 이것이 실패할 수도 있고, 사용자가 Emacs 내에서 다른 프린터를 사용하길 원할 수도 있다. 나머지 절에서는 사용할 프린터를 Emacs에 알려주는 방법을 설명하고자 한다.

로컬 프린터를 사용하길 원한다면 Lisp 변수

lpr-command

를 ""(Windows에서 기본값)으로 설정하고,

printer-name

을 프린터 포트명으로 설정하라(예: 일반적인 로컬 프린터 포트 "

PRN

", 또는 "

LPT2

", 또는 직렬 프린터에 "

COM1

").

printer-name

을 파일명으로 설정할 수도 있는데, 이런 경우 "인쇄된(printed)" 출력물은 사실상 해당 파일 끝으로 추가된다.

printer-name

을 "

NUL

"로 설정하면 인쇄된 출력물은 조용히 파기된다(시스템 널(null) 장치로 전송된다).

printer-name

을 해당 프린터에 대한 UNC 공유명으로 설정하면 다른 머신이 공유하는 프린터를 사용할 수도 있다(예: "

//joes_pc/hp4si

"). (여기서는 슬래시를 사용하든 역슬래시를 사용하든 상관이 없다.) 공유 프린트 이름을 알아내려면 서버 리스트를 얻기 위해 명령 프롬프트에서 '

net view

' 명령어를 실행하고, 해당 서버가 공유하는 프린터 이름을 (그리고 디렉터리를) 확인하려면 '

net view server-name

'을 실행한다. 아니면 데스크톱에서 '

Network Neighborhood

' 아이콘을 클릭하여 네트워크를 통해 프린터를 공유하는 머신을 검색하는 방법도 있다.

'

net view

' 의 출력에 프린터가 나타나지 않거나

printer-name

을 UNC 공유명으로 설정하여도 해당 프린터에 하드카피를 생성하지 않으면 '

net use

' 명령어를 이용해 "

LPT2

" 와 같은 로컬 프린터 포트를 네트워크를 통해 연결된 프린터로 연결할 수 있다. 예를 들어

net use LPT2: \\joes_pc\hp4si

를 입력하면 Windows는

LPT2

포트를 포착(capture)하여 출력된 자료를

joes_pc

머신으로 연결된 프린터로 방향을 다시 지정한다. 이 명령어를 호출한 다음

printer-name

을 "

LPT2

" 로 설정하면 네트워크를 통해 연결된 프린터에 하드카피를 생성할 것이다.

다양한 Windows 네트워크 소프트웨어를 이용해 Windows 에게 "

LPT2

" 와 같은 구체적인 프린트 포트를 포착하여 '

net use

' 대신

Control Panel->Printers applet

을 통해 네트워크 연결된 프린터로 방향을 다시 지정할 수 있다.

printer-name

을 파일명으로 설정하면 절대 파일명을 사용하는 것이 최선이다. Emacs는 현재 버퍼의 기본 디렉터리에 따라 작업 디렉터리를 변경하므로,

printer-name

에서 파일명이 상대명일 경우 출력이 이루어지는 버퍼의 디렉터리에 위치한 파일을 여러 개 얻게 될 것이다.

printer-name

값이 올바른데도 불구하고 인쇄(print) 시 프린터에 하드카피를 생성하지 않을 경우, 프린터가 일반 텍스트의 인쇄를 지원하지 않을 가능성이 있다(일부 저렴한 프린터에는 이 기능이 빠져있기도 한다.) 이런 경우 아래의 PostScript 출력 명령어를 시도하라.

print-buffer

와

print-region

명령어는

pr

프로그램을 호출하거나

lpr

프로그램으로 특수 전환을 이용해 각 인쇄된 페이지에 헤더를 생성한다. MS-DOS 와 MS-Windows 에는 보통 이러한 프로그램이 없으므로, 기본적으로

lpr-headers-switches

변수는 페이지 헤더를 인쇄하라는 요청을 조용히 무시하도록 설정되어 있다. 따라서

print-buffer

와

print-region

은 각각

lpr-buffer

및

lpr-region

과 동일한 결과를 생성한다. 적절한

pr

프로그램이 있다면(GNU Coreutils로부터),

lpr-headers-switches

를

nil

로 설정하면 Emacs 가

pr

을 호출하여 페이지 헤더를 생성하고,

printer-name

이 명시한 대로 출력물을 인쇄할 것이다.

마지막으로,

lpr

과 유사한 프로그램이 있다면

lpr-command

변수를 "

lpr

"로 설정하면 된다. 그러면 Emacs 는 다른 시스템에서와 같이 인쇄에

lpr

을 사용할 것이다. (프로그램명이

lpr

이 아닐 경우

lpr-command

를 적절한 값으로 설정하라.)

lpr-command

의 값이 " " 가 아닌 경우,

lpr-switches

변수는 표준 의미를 가진다.

printer-name

변수가 문자열 값을 가지면 Unix 에서와 마찬가지로

lpr

에 대해

-P

옵션에 대한 값으로서 사용된다.

유사한 변수 집합인

ps-lpr-command

,

ps-lpr-switches

,

ps-printer-name

(399 페이지의 31.6.2절 [PostScript 변수(PostScript Variables)] 참고)은 PostScript 파일을 어떻게 출력할 것인지 정의한다. 이러한 변수들은 non-PostScript 출력을 설명한 위의 본문에 제시된 변수들과 동일한 방식으로 사용된다. 따라서

printer-name

이 non-PostScript 출력에 사용되듯,

ps-printer-name

의 값은 PostScript 출력이 전송되는 장치명(또는 파일명)으로 사용된다. (두 개의 포트로 연결된 두 개의 프린터가 있고, 그 중 하나가 PostScript 프린터인 경우 사용자가 사용할 수 있는 변수 집합은 두 개가 있다.)

ps-lpr-command

변수의 기본값은 " " 로, PostScript 출력이

ps-printer-name

이 명시한 프린터 포트로 전송되는데,

ps-lpr-command

를 PostScript 파일을 수락하는 프로그램명으로 설정할 수도 있다. 따라서 non-PostScript 프린터를 갖고 있다면 이 변수는 PostScript 해석기 프로그램명으로 설정할 수 있다(예: Ghostscript). 해석기 프로그램으로 전달되어야 하는 스위치(switches)는

ps-lpr-switches

를 이용해 명시된다.(

ps-printer-name

의 값이 문자열이면

-P

옵션에 대한 값으로서 스위치 리스트에 추가될 것이다. 이는

lpr

을 사용 중일 경우에만 유용하므로, 해석기를 사용할 때는 일반적으로

ps-printer-name

을 문자열 이외의 값으로 설정해야만 무시될 것이다.)

예를 들어, 시스템의 기본 프린터에서 인쇄에 Ghostscript 를 사용하려면 아래의 내용을

.emacs

파일에 넣어라.

(setq ps-printer-name t)
(setq ps-lpr-command "D:/gs6.01/bin/gswin32c.exe") 
(setq ps-lpr-switches '("-q" "-dNOPAUSE" "-dBATCH"
			"-sDEVICE=mswinpr2" 
			"-sPAPERSIZE=a4"))

(이는 Ghostscript가 D:/gs6.01 디렉터리에 설치된 것으로 가정한다.)

MS-Windows에 폰트 명시하기(Specifying Fonts on MS-Windows)

Emacs 23부터는 폰트를 이름, 크기, 선택적 속성에 따라 명시하고 있다. 폰트를 명시하기 위한 포맷은 현대 프리(Free) 데스크톱에 사용되는 fontconfig 라이브러리로부터 비롯된다.

[Family[-PointSize]][:Option1=Value1[:Option2=Value2[...]]]

오래된 XLFD 기반의 포맷 역시 이전 기종과 호환성을 위해 지원된다.

Emacs 23 이상 버전은 다수의 폰트 백엔드를 지원한다. 현재

gdi

와

uniscribe

백엔드가 Windows에서 지원된다.

gdi

폰트 백엔드는 모든 Windows 버전에서 이용 가능하며, Windows가 본래부터(natively) 지원하는 모든 폰트를 지원한다.

uniscribe

폰트 백엔드는 Windows 2000 이상부터 이용 가능하고, TrueType 과 OpenType 폰트를 지원한다. 복잡한 레이아웃을 필요로 하는 일부 언어들은 Uniscribe 백엔드에서 적절하게 지원할 수 있다. 기본적으로 두 가지 백엔드가 지원될 경우 두 가지를 모두 활성화할 수 있으며,

gdi

보다

uniscribe

가 우선시된다. 이를 오버라이드하여 Uniscribe 를 이용할 수 있을 때에도 GDI 백엔드를 사용하려면

-xrm Emacs.fontBackend:gdi

명령행 인자를 이용해 Emacs를 호출하거나, 값이

gdi

인

Emacs.fontBackend

자원을 '

HKEY_CURRENT_USER\SOFTWARE\GNU\Emacs

' 또는 '

HKEY_LOCAL_MACHINE\SOFTWARE\GNU\Emacs

' 키에 추가하라(493 페이지의 D.1절 [자원(Resources)] 참고). MS-Windows 에서 모든 폰트 백엔드에 공통된 선택적 속성은 다음과 같다.

weight

폰트의 굵기를 명시한다.

weight=

없이 특수 값

light

,

medium

,

demibold

,

bold

,

black

을 명시할 수 있다 (예:

Courier New-12:bold

). 아니면 굵기는 100-900 사이의 수치적 값이거나,

font-weight-table

에 명명된 굵기여야 한다. 명시되지 않은 경우 일반 폰트로 가정한다.

slant

폰트가 이탤릭체인지 아닌지를 명시한다.

slant=

없이 특수값

roman

,

italic

,

oblique

를 명시할 수 있다(예:

Courier New-12:italic

). 아니면 기울기는 수치적 값, 또는

font-slant-table

에 명명된 기울기 중 하나여야 한다. Windows에서 150 이상의 기울기는 이탤릭체로, 그 미만은 로먼(roman)체로 취급된다.

family

폰트군을 명시하지만 보통은 폰트명 시작 부분에 명시될 것이다.

pixelsize

폰트 크기를 픽셀로 명시한다. 폰트군 다음에 명시되는 포인트 크기 대신 사용될 것이다.

adstyle

폰트에 대한 추가 스타일 정보를 명시한다. MS-Windows 에서는

mono

,

sans

,

serif

,

script

,

decorative

값이 인식된다. 이는 폰트군이 명시되지 않을 때에 가장 유용하다.

registry

폰트가 포함시킬 것으로 예상되는 문자 집합 레지스트리를 명시한다. 대부분의 TrueType 과 OpenType 폰트는 여러 개의 국가 문자 집합을 포함하는 Unicode 폰트가 되겠지만, 여기서

w32-charset-info-alist

의 구체적 레지스트리를 이용하면 폰트 선택 범위를 특정 문자 집합을 지원하는 범위로 좁힐 수 있다.

spacing

폰트의 간격을 명시한다.

p

간격은 비례 간격 폰트를 명시하고,

m

또는

c

는 일정한 간격으로 된 폰트를 명시한다.

foundry

Windows 에서 사용되지 않지만 국제적 목적이나 설정이 예상되는 코드의 문제를 방지하기 위해 bitmapped 폰트에는

raster

, scalable 폰트에는

outline

, 그 외에 결정되지 않은 타입의 폰트에는

unknown

으로 내부적으로 설정된다.

GDI 폰트에 특정적인 옵션은 다음과 같다.

script 폰트가 지원해야 하는 Unicode 하위범위를 명시한다. Windows에서 인식하는 스크립트로는

latin, greek, coptic, cyrillic, armenian, hebrew, arabic, syriac, nko, thaana, devanagari, bengali, gurmukhi, gujarati, oriya, tamil, telugu, kannada, malayam, sinhala, thai, lao, tibetan, myanmar, georgian, hangul, ethiopic, cherokee, canadian-aboriginal, ogham, runic, khmer, mongolian, symbol, braille, han, ideographic-description, cjk-misc, kana, bopomofo, kanbun, yi, byzantine-musical-symbol, musical-symbol, mathematical

이 있다.

antialias

안티얼라이징 방법을 명시한다.

none

값은 안티얼라이징을 사용하지 않음을 의미하고,

standard

는 표준 안티얼라이징을 사용하며,

subpixel

은 부분 픽셀 안티얼라이징(Windows 에서는 Cleartype 으로 알려짐)을,

natural

은 글자간 간견이 조정된 부분 픽셀 안티얼라이징을 사용함을 의미한다. 명시되지 않을 경우 폰트는 시스템 기본 안티얼라이징을 사용할 것이다.

다양한 Windows 특정적 기능(Miscellaneous Windows-specific features)

이번 절에서는 다양한 Windows 특정적 기능을 설명한다.

w32-use-visible-system-caret

변수는 시스템 탈자 기호(caret)를 표시할 것인지 결정하는 플래그(flag)다. 어떠한 화면 리더 소프트웨어도 사용하고 있지 않다면 nil을 기본값으로 하며, Emacs가 스스로 포인트의 위치를 나타내기 위해 고유의 커서를 그린다. nil 이외의 값은 Emacs가 시스템 탈자 기호를 이용해 포인트 위치를 나타낼 것을 의미하며, 이는 화면 리더 소프트웨어의 사용을 촉진시키고, Emacs를 실행할 때 그러한 소프트웨어가 감지되면 기본값이 된다. 이 변수를 nil이 아닌 값으로 설정하면 커서 표시에 영향을 미치는 다른 변수들은 어떠한 효과도 발생시키지 않는다.

이 범주에서 추가 Windows 특정적 변수들에 관한 정보는 Info 파일 emacs 의 '

Windows Misc

' 노드를 참고한다.