Gemini:Deep Research)에디터 전쟁: vi, Emacs

에디터 전쟁

서론 거인들의 등장 격전지 남겨진 유산 당신의 선택은?

서론 거인들의 등장 격전지 남겨진 유산 당신의 선택은?

서론: 끝나지 않은 성전

소프트웨어 개발 세계에는 수십 년간 이어져 온 논쟁이 있습니다. 바로 '에디터 전쟁'입니다. 이는 단순한 도구 선택을 넘어, 개발자들의 작업 철학과 정체성까지 반영하는 깊은 문화적 현상입니다. 이 애플리케이션은 에디터 전쟁의 핵심 주자인 Vi(Vim)와 Emacs를 중심으로 그 역사, 철학, 주요 특징 및 개발 문화에 미친 영향을 탐구합니다.

"에디터 전쟁은 종종 '성전(Holy War)'으로 묘사됩니다. 이는 그 논쟁이 지닌 강렬하고 거의 종교적인 열정을 의미합니다."

이 용어는 1991년 '해커 용어 사전'에도 기록될 정도로 널리 알려졌으며, 단순한 기술 비교를 넘어선 문화적 분열을 상징합니다.

이 애플리케이션을 통해 에디터 전쟁의 다양한 측면을 살펴보고, 왜 이 논쟁이 오늘날까지도 개발자들 사이에서 회자되는지 이해하는 데 도움이 되기를 바랍니다. 각 섹션은 보고서의 주요 내용을 요약하고 시각화하여 정보를 보다 쉽게 소화할 수 있도록 구성되었습니다.

거인들의 등장: Vi/Vim과 Emacs

에디터 전쟁의 중심에는 두 강력한 텍스트 편집기, Vi(와 그 후계자 Vim) 그리고 Emacs가 있습니다. 이들은 각기 다른 설계 철학을 바탕으로 개발되었으며, 수많은 개발자들의 사랑을 받아왔습니다. 이 섹션에서는 두 에디터의 탄생 배경, 핵심 철학, 그리고 주요 기능들을 살펴봅니다. 또한, 이들의 발전 과정을 간략한 타임라인으로 시각화하여 역사적 맥락을 이해하는 데 도움을 드립니다.

Vi/Vim: 효율성과 미니멀리즘

Vi는 1976년 빌 조이(Bill Joy)에 의해 유닉스 운영체제를 위해 개발되었습니다. 그 후계자인 Vim ("Vi IMproved")은 브람 물레나르(Bram Moolenaar)가 1991년에 공개했으며, 기존 Vi에 수많은 개선 사항을 추가했습니다.

핵심 철학:

• 모달 편집: 일반 모드, 삽입 모드 등 분리된 모드
• 키보드 중심: 마우스 사용 최소화, 홈 로우 유지
• 효율성 및 속도: 간결한 명령, 빠른 실행
• 미니멀리즘: 가볍고 빠른 실행

주요 기능:

• 다양한 모드 (일반, 삽입, 비주얼, 명령줄 등)
• 강력한 명령 조합 (예: `dw` - 단어 삭제)
• Vimscript를 통한 높은 사용자 정의 및 확장성
• 방대한 플러그인 생태계
• 구문 강조, 코드 폴딩, 분할 창 등
• 가볍고 빠른 시작 시간

주요 발전 과정

1976년

Vi 탄생

빌 조이가 ed 라인 에디터 기반으로 개발

1978년

BSD Unix 포함

Vi가 첫 BSD 유닉스 릴리스에 포함되어 널리 배포

1987년

STEVIE 등장

최초의 Vi 클론 중 하나로, Vim의 기반이 됨

1991년

Vim (Vi IMproved) 공개

브람 물레나르가 Amiga용으로 개발, 공개

2014년 (Neovim 포크)

Neovim

Vim을 리팩토링하고 Lua 통합 등 현대적 기능 추가

Emacs: 확장성과 통합 환경

Emacs("Editor Macros")는 1976년 MIT AI 연구소에서 데이비드 문과 가이 스틸 주니어가 TECO 편집기 매크로 세트로 처음 개발했습니다. 리처드 스톨만은 1984년 GNU Emacs 개발을 시작하여 Lisp 기반의 강력한 확장성을 갖춘 편집기로 발전시켰습니다.

핵심 철학:

• 확장성: Emacs Lisp를 통한 거의 무한한 기능 추가
• 통합 환경: 편집기를 넘어선 하나의 컴퓨팅 환경 지향
• 사용자 정의: 모든 측면을 사용자가 원하는 대로 변경 가능
• "모든 것이 명령이다"

주요 기능:

• Emacs Lisp(Elisp)를 통한 극강의 확장성
• 10,000개 이상의 내장 명령
• 주요 모드(언어별) 및 보조 모드(기능별)
• 파일 관리, 이메일, IRC, 게임 등 다양한 내장/추가 기능
• 자체 문서화 기능 (`help` 라이브러리)
• 모드리스 인터페이스 (수정자 키 광범위 사용)

주요 발전 과정

1976년

최초 EMACS 개발

MIT AI 연구소에서 TECO 기반 매크로 세트로 시작

1984년

GNU Emacs 개발 시작

리처드 스톨만이 자유 소프트웨어 대안으로 개발 착수

1985년

GNU Emacs 첫 공개

버전 13 출시, GNU 프로젝트 최초 프로그램 중 하나

1991년

XEmacs (Lucid Emacs) 포크

GNU Emacs 19 기반으로 Lucid Inc.에서 개발 시작

격전지: 주요 논점 비교 분석

Vi/Vim과 Emacs는 여러 측면에서 뚜렷한 차이를 보이며, 이는 에디터 전쟁의 주요 논쟁거리가 되어 왔습니다. 이 섹션에서는 사용자 인터페이스, 확장성, 학습 곡선, 성능 등 핵심적인 비교 지점들을 살펴봅니다. 특히 학습 곡선과 자원 사용량은 차트를 통해 시각적으로 비교하여 이해를 돕고자 합니다. 또한, 에디터 전쟁의 유머러스한 측면을 통해 각 진영의 특징적인 시각을 엿볼 수 있습니다.

학습 곡선 비교

Vim은 초기 학습 곡선이 매우 가파르지만 숙달 시 높은 효율성을, Emacs는 상대적으로 완만하지만 방대한 기능을 익히는 데 시간이 걸립니다.

자원 사용량 비교

일반적으로 Vim은 가볍고 빠르게 실행되는 반면, Emacs는 더 많은 시스템 자원을 사용하는 경향이 있습니다.

에디터 전쟁의 유머: "성전"의 단면

두 진영은 서로를 향한 유머러스한 비판과 풍자로도 유명합니다. 이는 각 에디터의 특징과 사용자 커뮤니티의 성격을 잘 보여줍니다.

Vim 사용자들이 Emacs에 대해:

• "Escape Meta Alt Control Shift" (수많은 키 조합 풍자)
• "Eight Megabytes And Constantly Swapping" (자원 소모 풍자, 과거형)
• "EMACS Makes Any Computer Slow"
• "괜찮은 편집기가 없는 훌륭한 운영체제"

Emacs 사용자들이 Vi/Vim에 대해:

• "반복적으로 삑삑거리고 모든 것을 망가뜨리는 두 가지 모드만 있다." (모달 편집 풍자)
• Vi 사용자들은 Emacs를 시작하는 방법조차 모른다고 주장 (학습 곡선 풍자)

구글 검색창에 'vim'을 검색하면 'emacs를 찾으셨나요?'라고 묻고, 그 반대의 경우도 마찬가지로 나타나는 이스터에그는 이 유서 깊은 경쟁을 재치있게 보여줍니다.

남겨진 유산: 개발 문화에 미친 영향

에디터 전쟁은 단순한 도구 경쟁을 넘어 소프트웨어 개발 문화 전반에 깊은 영향을 미쳤습니다. Vi/Vim과 Emacs의 철학과 기능들은 후대의 많은 텍스트 편집기와 통합 개발 환경(IDE)에 영감을 주었으며, 개발자들의 작업 방식에 대한 논의를 촉발시켰습니다. 이 섹션에서는 에디터 전쟁이 남긴 주요 유산과 현대 개발 환경에서 이 두 에디터가 여전히 중요한 위치를 차지하는 이유를 살펴봅니다.

개발자 문화의 지속적인 논쟁

에디터 전쟁은 '일을 수행하는 가장 좋은 방법'에 대한 근본적인 가정을 드러내며, 개발자들의 도구 선호와 작업 방식에 대한 깊은 성찰을 유도했습니다. 이는 단순한 기술적 우위를 넘어선, 개인의 철학과 편안함이 반영된 선택의 문제임을 보여줍니다.

텍스트 편집 도구의 진화

Vim의 모달 편집 방식과 효율성, Emacs의 극강의 확장성과 통합 환경이라는 개념은 이후 등장하는 많은 편집 도구에 영향을 미쳤습니다. 특히, Visual Studio Code, Atom, IntelliJ IDEA 등 현대적인 IDE들이 Vim 키 바인딩(Vim 모드)을 지원하는 것은 Vim의 강력한 편집 패러다임이 여전히 유효함을 증명합니다. Emacs 역시 'Evil-mode'를 통해 Vim과 유사한 경험을 제공하며 상호 영향을 주고받았습니다.

현대 개발 환경에서의 위상

최신 IDE의 발전에도 불구하고 Vim과 Emacs는 여전히 많은 개발자들에게 사랑받고 있습니다. 그 이유는 다음과 같습니다:

• 익숙함과 생산성: 오랜 시간 사용해 온 도구에서 오는 편안함과 근육 기억.
• 보편성과 접근성: 특히 Vim은 대부분의 유닉스 계열 시스템에 기본 설치되어 있어 어디서든 사용 가능.
• 가벼움과 속도: 제한된 자원 환경이나 원격 작업 시 유리.
• 강력한 사용자 정의: 사용자의 필요에 맞게 완벽하게 제어 가능.
• "작업에 비해 너무 많은 도구" 회피: 간단한 편집 작업에는 IDE보다 가벼운 편집기가 더 효율적일 수 있음.

결국, 에디터 전쟁은 특정 편집기의 승리로 끝나지 않았습니다. 대신, 각 에디터의 강점들이 현대 개발 도구에 흡수되고, 개발자들에게 더 다양한 선택지를 제공하는 방향으로 진화했습니다. 이는 텍스트 편집이라는 근본적인 작업에 대한 깊이 있는 고민과 혁신을 이끌어낸 중요한 과정이었습니다.

당신의 선택은?: 공존과 개인화의 시대

수십 년간 지속된 에디터 전쟁은 어느 한쪽의 완전한 승리로 끝나지 않았습니다. 대신, Vi/Vim과 Emacs는 각자의 강력한 철학과 기능을 바탕으로 현대 개발 환경에서도 여전히 중요한 위치를 차지하며 공존하고 있습니다. 이들의 경쟁은 텍스트 편집 도구의 발전을 촉진했고, 개발자들에게 더욱 다양한 선택지와 강력한 기능을 제공하는 계기가 되었습니다.

"궁극적으로 Vim과 Emacs(또는 현대 IDE) 사이의 선택은 개인적인 선호, 작업 흐름 요구 사항, 그리고 이러한 강력한 도구를 숙달하는 데 시간을 투자하려는 의지로 귀결됩니다."

단 하나의 '우월한' 편집기는 존재하지 않으며, 가장 '적절한 도구'는 개인의 필요와 작업 방식에 따라 달라집니다. 중요한 것은 작업을 가장 효율적으로 완료하는 데 도움이 되는 도구를 선택하고, 그 도구를 깊이 있게 활용하는 것입니다.

에디터 전쟁은 이제 격렬한 대립보다는 각자의 장점을 살린 공존의 시대로 접어들었습니다. Vim의 효율적인 모달 편집, Emacs의 무한한 확장성 같은 핵심 아이디어들은 현대 IDE에도 영향을 미치며 개발자들의 생산성 향상에 기여하고 있습니다. 이제 개발자들은 과거의 '성전'에 얽매이기보다, 다양한 도구의 장점을 취합하여 자신만의 최적화된 개발 환경을 구축하는 실용적인 접근 방식을 취하고 있습니다.

이 애플리케이션이 에디터 전쟁에 대한 이해를 높이고, 자신에게 맞는 도구를 선택하는 데 조금이나마 도움이 되었기를 바랍니다.

© 2024 에디터 전쟁 분석. 이 애플리케이션은 제공된 보고서 내용을 기반으로 생성되었습니다.

유튜브 19금 광고 댓글 요즘 스타일.

 이제는 원문 그대로 복사해서 안올리고,(아무래도 유튜브에서 잡는것 같다.)

몇개를 섞어서 한문장으로 ai 사용해서 바꾸고 그대로 댓글을 단다.

그리고 다른 19금 광고계정으로 추천을  올린다. 

sxhkd Daemon : Simple X hotkey daemon

 # ~/.config/sxhkd/sxhkdrc 

alt + {a-z}
    bash ~/bin/shotcuts/shortcut.sh {a-z}

 

kde를 주로사용평소 KDE 환경에서 GUI 설정을 통해 단축키를 만들어 사용했지만, 이 분의 SXHKD 설정 파일을 보니 X 윈도우 환경에서도 간편하게 단축키를 정의할 수 있다는 점이 인상적입니다. (참조 링크)

특히 PDF 검색 workflow가 흥미롭습니다. 파일 목록을 SXHKD를 통해 넘겨주면, 가운데 창에서 선택하여 PDF 뷰어로 바로 열람하는 방식인데, 파일 목록을 보여줄 때 미리보기 기능까지 고려했을 가능성이 엿보입니다.

파일 검색에 활용된 rofi는 fuzzy 검색을 지원하므로, 파일명은 물론 내용, 저자, 특정 저널까지 자유롭게 검색할 수 있다는 장점이 있습니다. 특히 지도교수님이나 본인의 저서를 검색할 때, 연구자 규모를 고려하면 검색 결과가 많지 않을 것이기에 더욱 효과적으로 작동할 것으로 보입니다.

텍스트 노트 작성 환경도 눈여겨볼 만합니다. 이 분은 Vim을 사용하여 LaTeX 문서를 편집하고, ranger라는 텍스트 기반 파일 관리자를 활용합니다. 필요에 따라 midnight commander와 같은 다른 툴을 사용하거나, 단순히 해당 디렉토리에서 Bash를 열어 작업할 수도 있습니다.

ranger가 w3m-img와 연동하여 이미지를 다운로드하는 것을 보면, HTML 뷰어 기능이 내장되어 있을지도 모르겠습니다. 직접 사용해 보니 macOS의 Finder와 유사한 세 개의 창으로 구성된 파일 관리자입니다. 상위 폴더, 현재 폴더 (파일 목록), 그리고 선택한 폴더의 내용물 (파일이면 미리보기)을 직관적으로 보여줍니다. Alacritty, Zed Warp과 같이 그래픽 지원 터미널(흔히 Kitty Graphics라고 불리는)을 사용하는 점도 주목할 만합니다.

case $key in
	p ) cd ~/phd/papers;
	pdf_file="$(ls . | rofi -theme ~/.config/rofi/theme-wide.rasi -i -dmenu)";
	[ -z "$pdf_file" ] && exit 0;
	[ -f "$pdf_file" ] && zathura "$(realpath "$pdf_file")" || sensible-browser "https://google.com/search?q=$pdf_file" ;;
	r ) $terminal "ranger ~/phd/notes/$(date +"%F")" ;; m ) $terminal "vim ~/phd/notes/master.tex ;;
	n ) $terminal "cd ~/phd/notes/$(date +"%F"); $vim ~/phd/notes/$(date +"%F")/note.tex" ;;
	o ) zathura ~/phd/notes/master.pdf ;;
	x ) open_xournal ;;
	f ) $node $root/copy-pdf-reference.js ;;
	esac

언뜻 보면 특별한 설정은 아닌 듯하지만, KDE나 GNOME 역시 자체적인 전역 단축키 설정을 지원하기 때문입니다.

SXHKD의 장점은 컴퓨터 시작 시 자동으로 실행되지 않도록 설정하고, 필요할 때만 실행하여 작업할 수 있다는 점입니다. 또는 작업 종류에 따라 전역으로 SXHKD 설정을 전환하며 사용할 수도 있습니다. 실제로 현재 설정도 기본적으로 컴퓨터 시작 시에는 활성화되지 않도록 되어 있습니다.

rofi를 활용한 fuzzy 검색 기능은 Plasma Runner로도 유사하게 구현할 수 있으며, 결국 모든 기능에는 대안이 존재합니다. 하지만 이 분의 설정처럼 여러 툴을 유기적으로 묶어 마치 하나의 서비스처럼 효율적으로 사용하는 방식은 정말 대단하다고 생각합니다.

참고 링크를 따라가 보면, LaTeX 문서 작업 중 급하게 그림을 그려야 할 때 Inkscape를 실행하고, 키보드 이벤트를 캡처하여 미리 설정된 펜 굵기, 대시 타입, 펜 색상 등으로 그림을 그리고, 그림에 LaTeX 주석까지 쉽게 추가할 수 있도록 설정해 둔 것을 확인할 수 있습니다. 심지어 그림을 저장하고 Vim으로 돌아오면 작성하던 LaTeX 문서에 해당 그림을 바로 삽입할 수 있도록 연동해 놓았습니다.

전반적으로 이 분의 작업 방식은 다양한 툴을 효율적으로 연동하여 개인 작업 환경을 극대화한 좋은 예시라고 생각하며, 각 툴의 강력한 기능을 활용하고 워크플로우에 맞게 통합하는 아이디어를 얻을 수 있었습니다. 특히 단축키를 통해 자주 사용하는 작업을 빠르게 실행하고, 텍스트 기반 툴을 생산적으로 활용하는 점은 저도 제 작업 환경에 적용해 볼 만한 부분입니다.

무서운 가짜 유튜브 댓글들...

원본과 스팸채널이 같이 나타난건 처음이네... 이게 뭐야... 

Amarok 3.2.1설치 과정 >> 3.1.1 (google gemini )

 제공해주신 bash history를 분석해 보니, Amarok 설치 과정에서 겪으신 다양한 문제와 해결 과정을 확인할 수 있었습니다. 몇 가지 주요 사항을 정리해 드리겠습니다.

1. 최신 tarball 버전 호환성 문제:

• amarok-3.2.1 tarball을 다운로드하고 설치를 시도했지만, 배포판과의 호환성 문제로 인해 실패했습니다.
• ChangeLog를 확인하여 호환되는 버전인 amarok-3.1.1을 다운로드하고 설치를 다시 시도했습니다.
• 이는 최신 버전의 tarball이 항상 모든 배포판과 호환되는 것은 아니라는 것을 보여줍니다.

2. 의존성 문제 해결:

• libqt5quick5, qtdeclarative5-dev, qtbase5-dev, libqt5svg5-dev, libkf5kcmutils-dev, libkf5dnssd-dev, libkf5threadweaver-dev, libkf5texteditor-dev, libkf5package-dev, libmariadb-dev, libfftw3-dev 등 다양한 의존성 패키지를 설치해야 했습니다.
• apt-cache search 명령어를 사용하여 필요한 패키지를 검색하고 sudo apt-get install 명령어를 사용하여 설치했습니다.
• 패키지 관리자에서 모든 의존성 문제가 해결되지 않을 수 있다는 것을 알 수 있습니다.

3. taglib 관련 문제 해결:

• libtaglib-ocaml-dev 패키지를 설치했지만, Amarok 빌드에 필요한 taglib 버전과 맞지 않아 제거했습니다.
• taglib_1.13.1.orig.tar.gz tarball을 다운로드하고 수동으로 빌드 및 설치했습니다.
• .cmake 파일이 제대로 설치되지 않아 CMAKE_MODULE_PATH 변수를 사용하여 CMake가 해당 파일을 찾도록 설정했습니다.

4. .cmake 파일 관련 문제 해결:

• .cmake 파일이 제대로 설치되지 않아 Amarok 빌드 과정에서 오류가 발생했습니다.
• CMAKE_MODULE_PATH 변수를 사용하여 CMake가 .cmake 파일을 찾도록 설정했습니다.
• 이는 tarball 설치 시 .cmake 파일이 제대로 복사되지 않는 문제가 발생할 수 있다는 것을 보여줍니다.

5. apt-get의 정규 표현식 지원 활용:

• apt-get 명령어를 사용할 때 정규 표현식을 사용하여 패키지를 검색하고 설치했습니다.
• 이는 apt-get이 정규 표현식을 지원한다는 것을 보여줍니다.

전반적인 분석:

• Amarok 설치 과정에서 다양한 의존성 문제와 .cmake 파일 관련 문제를 겪으셨습니다.
• apt-get, cmake, grep, vim 등 다양한 명령어를 사용하여 문제를 해결했습니다.
• 배포판과 tarball 버전의 호환성, 의존성 문제, .cmake 파일 관련 문제 등 tarball 설치 시 발생할 수 있는 다양한 문제에 대한 경험을 쌓으셨습니다.

추가 조언:

• Amarok 설치 전에 배포판과 호환되는 버전을 확인하는 것이 좋습니다.
• 의존성 문제를 해결하기 위해 필요한 패키지를 미리 설치하는 것이 좋습니다.
• .cmake 파일 관련 문제가 발생하면 CMAKE_MODULE_PATH 변수를 사용하여 해결할 수 있습니다.
• apt-get의 정규 표현식 지원을 활용하면 패키지 검색 및 설치를 효율적으로 수행할 수 있습니다.

이러한 경험을 통해 Amarok 설치 및 리눅스 시스템 관리에 대한 이해를 높이셨기를 바랍니다.

역겨운 기사 ( 이데일리 성주원)

 

"궤변에 가까운 판단" 최재형 前감사원장, 이재명 무죄 판결 비판

[이데일리 성주원 기자] 이재명 더불어민주당 대표의 공직선거법 위반 사건 항소심 무죄 판결을 두고 법조계가 술렁이고 있다. 감사원장과 21대 국회의원을 지낸 법원장 출신 최재형(사법연수원 13기) 변호사는 27일 자신의 SNS를 통해 해당 판결문을 조목조목 분석하며 강도 높은 비판을 제기했다.

나무위키에 검색하니까, 국민의힘 서울특별시 당협위원장으로 나오는데, 전 감사원장이라고 써서 여론조작을 시도하네...
21대 국회의원이라고 적어놓는거 보니까, 영감님 소리 안남기면 최재형씨가 싫어하나보긴 하나본데,   왜 당을 안적어 놓냐... 
국민의힘 전국회의원이자 종로에서 국회의원 하고싶은데 떨어진 사람이 언론에다가 한소리 하는거를... 참...

이러니 기자들이 욕을 먹지...

2022년 3월 재보궐선거에서 이낙연의 중도 사퇴로 인해 더불어민주당이 보궐선거에서 종로구에 후보를 내지 않기로 결정한 가운데, 국민의힘 후보로 전략 공천되어 종로구 국회의원 선거에 출마하여 당선 이후 21대 국회의원을 역임하였다.

그것도 이낙연???덕에 국회의원한 했네... 뭐 국민의 선택을  받지도 않은건가... 양당제에서 이게 뭐냐.

역겨운 언론(연예기사)

 토 나오는 역겨운 기사이다.

건축 하는 일에 관심있다면 표준 시방서를 읽어보라.

 그렇다고 하더라...

관심있는 분야들은, 그 학과의 커리큘럼을 보고 있다.

학습 순서를 알면 책만 읽으면 얼추 알아 듣게 되어 있다...

당연한게, 예술계랑 다르계 인문 및 자연과학은 해당 분야의 전문지식 같은건 가지고 오지 않고

대학에 오기 때문이다. 당연히 고등학교를 졸업하고 대학까지 나온 사람은 충분히 순서만 지키면

따라갈 수 있다.

근데, 세상 나가서 하는 일도 마찬가지인가보다. 

표준시방서를 보라.

linux USB 드라이버 관련 트릭. (unsigned 16)을 1byte만 쓸 때 쉬운 표현법.(빅엔디안 표현.)

 

usb_control_msg 관련해서, u16 memory offset을 써야하는데,

(unsigned short) 0x32 보다 더 정확하게 쓰는 법으로 다른 사람이 쓰는 트릭을 쓰자면

"\x32"라고 쓰는 것, 이것은 0x32 0x00 과 같다. 

자동으로 널문자가 붙는다. unsigned short는 0x00일지 0x32일지 알 수 없다. Device dependent한 결과가 나오겠지만,

"\x32"라고 쓰면 그런거 없다. 무조건이다.  네트웍이나 디바이스간 통신 등에서 

다양하게 쓸 수 있을 방법으로 보인다. 뭐 규약에 맞추는거지 뭐 ...

빅엔디안 잘쓰는 방법

c99이후에 쓰이는 배열 초기화 문법.

 

리눅스 커널 모듈관련해서 패치 제작 관련해서 만져보다가 발견했다. 

구조체 초기화처럼 

static unsigned int video [] = { [0 ... MAX_ARRAY]  = -1U };

와 같은 명령어가 가능하다. 

이와 관련해 찾아보니, 배열을 { [0] = 1,   [1] = 2} 와 같은 방식으로 처리하는 것은, 

c99에서 도입된 방법이라는 것을 알 수 있었으며,

...을 사용해 typing을 줄이는 기술은, gnu c compiler 쪽 특수 문법임을 확인했다.

ISO C99에는 없는 기능이다. 

리눅스 커널모듈이니, gnu c99 문법은 적용가능하다. 

c89에서는 { 0,1,2,3,4} 이런 식으로 위치지정없이 순차적으로만 기입할 수 있다. 

그리고 ... operator는 case 문에서도 사용가능하다. 

_Bool lowercase_eh(char c)
{
    switch(c) case 'a' ... 'z': return 1;
    return 0; 
}   

참조:참조(Stack Overflow)