text file containing text files

내 에디터의 화면(현황)

지금 현재의 회사 컴퓨터의 에디터 화면입니다. 열어놓은 문서가 너무 많습니다.


그중에서도 제목없는 문서들이 굉장히 많습니다.
이 제목없는 문서들에도 필요한 내용들이 담겨 있는데, 대게 화일로 저장하지 않고 실행해본 스크립트언어의 코드들이 들어 있습니다.
(emeditor가 지원하는 WSH(즉, jscript나 vbscript)로 문서의 저장여부에 상관없이 현재 작성중인 ActiveDocument의 내용을 Windows Scripting Control에 전달해 실행해 보는 것이 가능합니다.)

전에는 Tab을 한줄로 하고, 기본으로 제공하는 Open Documents Plug-in을 사용해 보기도 했습니다만, Open Documents Plug-in으로도 창의 세로폭으로 나열할 수 있는 양보다 더 많은 문서를 열면 Scroll bar가 생기는데, Scroll bar로 올렸다 내렸다 하며 찾아 클릭해 activate시키는 것이 훨씬 더 불편하더군요 그래서 그냥 위의 이미지 대로 이렇게 쓰고 있었습니다.

그런데, 오늘 퇴근하면서 생각한 것입니다만, 하나의 에디터 창에 여러개의 문서를 함께 가지고 있으면 안될까 하는 생각이 들었습니다.

현대인에게의 (휴먼 인터페이스로서의)파일시스템(현황을 고찰)

우리가 현재 쓰고 있는 파일시스템은 User가 사용하는 인터페이스에 있어서 꽤 오래전의 그것과 크게 다르지 않습니다. 디렉토리가 있고, 파일이 있고, 하나의 파일에는 하나의 내용이 있습니다.
파일의 역할에 맞는 파일의 확장명이 있고, 이 확장명에 따라 기대되는 사용방법이 있습니다. (shell에 따라 shebang으로 기대하는 역할을 부여하기도 합니다.)

이러한 방식은, 컴퓨터에게 있어서는 꽤나 적합한 설계이고, 그렇기 때문에 지금까지도 이 방식이 사용되고 있는 것이라고 생각합니다..

그런데, 컴퓨터의 용량이 커지고,고속화된 지금. (그것도 C언어가 고안되던 70년대에 비하면 매우매우.) 전문직업인으로 컴퓨터를 다루는 사람에게는 매우 많은 파일을 다루게 되는 일이 많습니다.

오나마에의 스즈끼상은 이클립스를 2년째 정도 끈 적이 없는데, 언제나 열려있는 파일의 갯수는
50+ 라고 나옵니다. (100개 정도를 닫아보았는데도 50+로 표시되는 것이 똑같습니다.)

Legacy팀의 Gohko상은 vim를 잘 다루는데, 여러 디렉토리와 파일로 나누어 관리하는 것이 vim로는 귀찮았는지(vim은 훌륭한 에디터이지만, 여러 파일을 다루기는 역시 좀 귀찮겠지... 싶습니다.) 하나의 파일에 몽땅 적습니다. (그리고 나는 이 방식이 좋지 않다고 생각합니다.) 지금 작업중인 프로젝트에서는 perl 스크립트 코드가 1만줄이 넘었습니다. OTL.

Hmmm.....(문제를 일반화)

컴퓨터가 작업하는 단위로서 파일이라는 단위는 꽤 적합하다라고 생각한다고 얘기했습니다.
그런데, 전문 직업인이 작업으로 생각하고 있는 하나의 작업은 하나의 파일 이상일 때가 있습니다.

예를 들면 c언어의 프로그래밍에서 c파일은 대게 c파일과 h파일, make파일로 나뉩니다.
자바등과 같이 객체지향의 프로그래밍의 경우라면, 전통적인 방법으로 하나의 파일에 하나의 public 클래스를 가지도록 구성하지만, 작업의 단위라면 여러개의 클래스가 동시에 손대야 할 경우가 생깁니다.(interface와 class, abstract class의 구분도 그렇고, BL, DAO의 구분도 그렇습니다. ant니 properties니 xml이니 하는 것 까지 생각하면 더욱 그렇습니다.)
aspx파일과 그 code behind파일도 그렇구요.

그렇다면?

그렇다면 에디터에서의 하나의 편집중인 Document는, 여러개의 문서의 내용을 포함하고 있으면 어떨까 하는 것을 생각해 보았습니다.

SDI를 바탕으로 하는 MDI(고안)

단순하게 생각해 보았습니다.
하나의 SDI인 ActiveDocument에서, 파일을 구분하는 markup이 있으면, 하고 말입니다.
즉, 하나의 텍스트 파일이 작은 project파일과 같이 작동하는 방법입니다.
이렇게 말이죠.

<file path="c:\temp\makefile">

</file>
<file path="c:\temp\test.h">

</file>
<file path="c:\temp\test.c">

</file>

<file path="${ActiveDocument.Path}\makefile">
</file>

save를 하면 덩치가 큰 이 파일하나와 각 markup에 있는 파일들이 생성 또는 update되도록 하는 것이 기본 조건입니다.

이 방식으로는 100개 이상의 파일이니, 1만줄이니 하는 그런 큰 규모의 프로젝트를 하나의 SDI로 대체할 수는 없습니다만, 작업의 단위로 나눠 사용하기에는 나쁘지 않을까 합니다.

준비해야할 매크로로는

현재 커서가 있는 부분의 파일을 save 하는 매크로
현재 커서가 있는 부분의 파일을 load 하는 매크로
ActiveDocument가 포함하고 있는 파일을 전부 save 하는 매크로
실행커맨드가 있는 부분의 내용을 실행하는 매크로

등이 있으면 편리하겠군요.

아이디어는 여기까지 입니다만, 효율성이 많이 좋을 지는 사용해 봐야 알겠습니다.
#적어도 lex & yacc작업할 때는 편해지겠다는 생각이 듭니다.