▲

Microsoft Edit

 (github.com/microsoft)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • Microsoft Edit는 클래식 MS-DOS Editor에 오마주를 바치는 간단한 텍스트 편집기임
  • VS Code와 비슷한 현대적인 인터페이스와 입력 컨트롤을 제공함
  • 개발 목표는 터미널에 익숙하지 않은 사용자도 접근할 수 있는 편집 환경 제공임
  • Search and Replace 기능을 위해 ICU 라이브러리 선택적 의존성을 가짐
  • 패키지 관리자를 위한 명확한 실행 파일 네이밍 및 환경 변수 옵션 안내를 포함함

오픈 소스 프로젝트 개요

  • Microsoft Edit는 간단한 작업을 위한 고전 에디터 스타일의 텍스트 편집기임
  • MS-DOS Editor를 현대적으로 재해석한 것이 특징이며, VS Code 스타일의 친근한 UI와 입력 방식을 적용함
  • 특별히 터미널 사용 경험이 적은 유저도 쉽게 사용할 수 있는 단순성에 중점을 두어 설계됨

특징 및 기능

  • 최소한의 복잡도를 가지면서 기본적인 텍스트 편집 작업을 간편하게 수행할 수 있음
  • 인터페이스는 익숙한 느낌을 제공하며, 접근성과 사용 편의성을 중시함
  • ICU(International Components for Unicode) 라이브러리에 선택적으로 의존하여 Search and Replace 기능을 지원함

패키지 관리자 및 패키징 관리자를 위한 주의사항

패키지 네이밍

  • 기본 실행 파일명은 "edit" , 대체 이름은 "msedit" 임
  • 기존 시스템 명령어 "edit"와 충돌 문제로 인해 "msedit" 등 대체 네이밍을 권장함
  • "ms-edit" 등의 이름은 피하는 것을 권장함

ICU 라이브러리 네이밍(SONAME)

  • Search and Replace 기능을 위해 ICU 라이브러리를 사용할 수 있음
  • 각 OS별 기본적으로 찾는 라이브러리는 다음과 같음
    • Windows: icuuc.dll
    • macOS: libicuuc.dylib
    • UNIX 및 기타: libicuuc.so
  • 시스템 환경에 따라 라이브러리 이름(SONAME)이 다를 경우 각종 환경변수(EDIT_CFG_ICUUC_SONAME, EDIT_CFG_ICUI18N_SONAME 등)로 설정 가능함
  • ICU export symbol 명명 규칙이 다를 경우를 위한 추가 환경 변수 제공

기타

  • ICU 리네이밍 자동 감지, C++ 심볼 지원 등 추가 옵션이 있음
  • 해당 설정 검증을 위해 cargo test -- --ignored 명령으로 테스트 가능함

결론

  • 간단함과 접근성을 중시하면서도, 유연한 환경 구성이 가능한 오픈 소스 편집기
  • 개발자, 오픈 소스 기여자, 패키지 관리자에게 명확한 가이드라인과 높은 호환성을 제공함
▲
GN⁺ 8시간전  [-]
Hacker News 의견

  • 그냥 “내가 하고 싶어서” 만든 프로젝트라는 이야기인데, 나도 그런 식으로 뭔가를 만들어보며 내부 동작 원리 이해하는 경험 많이 했던 기억임. 하지만 Turbo Vision을 FPC로 다시 쓰고 여러 대상을 지원해서 컴파일하는 버전은 이미 20년쯤 됐음. Turbo Vision은 최고의 텍스트 모드 윈도우 라이브러리라고 생각함. 진짜 재미는 전체 텍스트 화면을 배열로 매핑하는 부분에서 시작임. var Screen: Array[1..80,1..25] Of Byte Absolute $B800 뭐 이런 식이었던 걸로 기억함. Turbo Vision이 진짜 혁신이었던 건 이동 가능한 (비)모달 윈도우였다는 점임. 그러니까 결국 저 배열을 루프 돌리면서 끊임없이 다시 쓰는 거였음. 꽤 빨랐음. 나도 저 라이브러리로 꽤 많은 수익을 올린 기억임

    • 궁금한 사람을 위해 요즘 버전 C++ Turbo Vision, 그리고 유니코드 지원까지 하는 포트가 있음 https://github.com/magiblot/tvision

    • TP의 배열은 row-major로 되어 있었음. 문자 하나가 2바이트(글자+속성)로 구성됨. 그래서 심지어 array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000 이런 편의성이 있었음. 흑백 텍스트 디스플레이에서는 $B800을 $B000으로 바꾸면 됨. 예시로 Hercules 같은 환경

    • VSCode에서 저런 인터페이스가 터미널에서 (심지어 원격으로도) 되면 정말 좋을 것 같음

    • 어떻게 그 라이브러리로 돈을 벌었는지 궁금함. 비법 좀 알려줬으면 함

    • 요즘 새로 나오는 TUI 프레임워크 볼 때마다 항상 떠오르는 생각, “Turbo Vision만 못함”이라는 아쉬움

  • 한편으로는 AI Copilot 같은 불필요한 덩치를 Notepad에 억지로 넣고 있음. 원래 Notepad의 핵심은 아무 기능 없이 '하나만' 제대로 하는 거였던 기억임

    • 새로운 Edit도 이런 결정에서 자유롭지 못함. Satya 시대에 MS가 FOSS를 좋아하는 척했지만 Gates/Balmer 시절이 훨씬 윈도우 개발자에게 친절했던 기억임. 지금은 웹/데스크톱 프레임워크가 뒤섞였고, 내부적으로조차 잘 안 쓰는 판임. 예전 VS 위저드나 플러그인 대신 CLI 툴로 엑셀 파일 덤프나 하는 식. 세대 간 윈도우 개발 문화나 관리진에 노하우 부족함이 잘 드러남

    • Raymond Chen이 Notepad가 의외로 많은 테스트에 쓰인다는 말 한 적 있음. 심플한 기능이지만 실험용으로 자주 쓰인다는 내용 https://devblogs.microsoft.com/oldnewthing/20180521-00/?p=98795

    • 윈도우11 새 Paint에서 스크린샷 붙여넣기해 봤는데, 최소화된 상태에서도 CPU 5%를 계속 쓰고 메모리는 250MB쯤 차지함. RAM이야 그렇다 쳐도 CPU를 이렇게 낭비하는 건 좀 아니라는 생각임. 예전에는 자부심이나 품질 관리라는 게 있었던 기억임

    • ISP가 간헐적 장애(IPv4/MTU 문제) 있을 때, Notepad에서 저장조차 안 됨. 억지로 꺼야 가능했음. 당시에는 Wireguard로 임시 우회 세팅하던 중이었음

    • 모던 notepad를 삭제하면, 시작 메뉴에서 예전 notepad를 검색해도 안 나옴

  • 한 달 전쯤 MS가 윈도우 사용자에게 더 친숙한 리눅스 배포판을 냈다는 얘길 들은 기억임. 기억상 단순한 GNOME 환경이었고 특별한 점은 없었음. 오히려 MS가 자기만의 리눅스 배포판을 만들면서 bash를 powershell로, Edit를 vim/nano 등으로 대체하고, .NET이나 Visual Studio Code도 기본 개발 툴로 포함할 수 있었을 텐데... MS가 이걸 WSL의 기본 배포로 활용했다면 전쟁에서 이기진 못해도, 사용자 점유율은 오를 수 있었겠다는 아쉬움임. MS가 커널까지 장악하진 못하더라도 사용자 공간(userland) 지배는 가능함. 많은 윈도우 유저들이 기본 설치 앱으로 MS의 툴을 자연스럽게 쓰게 만들 수밖에 없음. 이제 Microsoft Edit도 리눅스에서 사용 가능함. Powershell같이 다른 앱들도 마찬가지고. 만약 10년 전 이런 전략을 썼다면 오늘날 WSL에서 MS 배포판이 상위 5위 안에 들 수도 있었다는 상상임. 큰 기업(M$)들이 내 개인 PC까지 영향력을 뻗칠 수 있다는 점에서 약간 불편함. 결국은 이 Microsoft Edit가 Co-Pilot 기본 제공될 날을 상상 중임

    • 언젠가는 MS가 최소한 Windows Server나 임베디드 윈도우 같이 일부 영역부터 리눅스 쪽으로 점차 이동할 거라 생각함. 장기적으로는 윈도우 데스크톱도 점진적으로 변화해서 ‘Windows Legacy’ vs ‘Windows Linux Workstation’ 옵션이 나올 것 같음. 리눅스 커널 + 튜닝된 와인(WINE) + 일부 레거시용 통합 VM 형태로 진화 예상함. 문제는 NT 커널이 설계상 리눅스보다 앞선 점이 많음(예: GPU 드라이버 전체 충돌 후 복구 가능 등). 하지만 윈도우 자체는 점점 자산보다 부담으로 변하는 중임. 실제로 MS의 성장 동력은 Azure & Office 365이고, 윈도우 라이선스는 거의 정체 상태임. 최소한 리눅스 기반 윈도우 서버와 워크스테이션은 기대 가능함

    • Azure Linux(구 CBL-Mariner)는 컨테이너, VM, 서버 용도로 만든 MS 공식 리눅스 배포판임. 단순 윈도우 유저를 위한 스킨이나 데스크탑 환경과는 구분 필요함

    • MS가 예전에 만든 리눅스 배포판 이름 “Xenix”가 있었지만, 성적이 안 좋았던 기억임

    • WSL 탄생 배경은 대기업 내 개발자가 리눅스 환경 필요성이 높았기 때문임. IT 지원 쪽은 리눅스를 잘 모르고, 굳이 지원하고 싶어하지도 않음. WSL이 이런 문제를 해결함. 실제로 많은 개발자가 리눅스를 쓰고 싶어하지 않고, 터미널도 서툰 경우가 많음. GUI 툴에 의존함

    • MS가 윈도우 유저 감성 만족시키려고 자체적으로 비밀 배포판 유지한다는 건 다소 비현실적임

  • 이 소식이 일주일 사이 3번이나 올라올 만큼 화제임

    1. 作者 포스트 - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu 공식 포스트 - https://news.ycombinator.com/item?id=44306892
    3. 그리고 이번 포스트

  • 원래 edit.com(DOS 6.22부터, 이후 7.0/윈95)은 내 첫 IDE였음. 시작은 qbasic이었고 edit.com과 거의 같은 프로그램임. C/C++을 djgpp로 배우면서도 edit.com을 쭉 사용했음. 내 “프로젝트 파일”은 e.bat로, edit file1.cpp file2.cpp...처럼 여러 파일을 한 번에 열 수 있었음. 다른 에디터는 멀티 파일 전환이 불편했는데, alt-1,2,3...으로 바로 전환되는 게 마음에 들었음. 난 아직도 에디터 단축키 바꿀 때 이 스타일을 꼭 유지함. 비록 코드 에디터로는 구린 편이었음. 문법 하이라이트도 없고, 들여쓰기 지원이 별로였음(그래서 처음에는 들여쓰기를 두 칸으로 했는데, 수동으로 하기도 편했음). 그래도 작성한 코드에 대한 즉각적 피드백과 친숙함이 최고였음. qedit 같은 에디터도 있었지만 내 취향은 아니었음, 유닉스 계열 에디터는 도스에서는 별로였단 생각임. 이번 새로운 editor는 멀티 버퍼 지원은 되지만, 내가 익숙한 키 바인딩 방식은 적용 안 된 듯함

    • 이슈로 제기하면 좋겠음. 이런 피드백은 초기에 전달하면 실제 반영되는 경우 많음. 그리고 진짜 그냥 비슷한 수준이 아니라, edit.com은 qbasic에 플래그 하나 추가해서 부팅된 것과 똑같았음. 직접 qbasic에 그 플래그 줘서 쓰기도 했음 https://news.ycombinator.com/item?id=44037509

    • 문법 하이라이트는 없었지만, 문법 대문자화(예: 예약어 자동 대문자 변환)는 있었음. 예를 들어 한 줄을 전부 소문자로 입력해도 엔터 치면 예약어가 자동 대문자로 바뀌었음. 별 거 아니지만 꽤 편했음

    • copy con 시절에 비하면 edit가 정말 구세주였음

  • 여러 면에서 마음에 든 점이 많음. 우선, 의존성 없는 깔끔한 리스트! 완전히 반함. 전체 TUI를 이 한 에디터를 위해 직접 만들었다는 게 믿어지지 않음. 다이얼로그, 파일 브라우저까지 있음. 내 프로젝트에도 적용해보고 싶음. 혹시 관계자 있으면 Ratatui를 왜 안 썼는지 궁금함. 코드 품질이 워낙 뛰어남. 한 마디로: Bravo!

  • 예전에는 micro[1]를 이런 텍스트 에디터를 찾는 사람에게 추천했었음. 이제는 뭘 추천할지 고민임

    • https://micro-editor.github.io/

    • 내 생각엔 추천을 바꿀 필요 없음. edit는(최소한 내가 써보니) 문법 하이라이트도 지원 안 함

    • 마지막에 체크해봤는데, micro라기보단 macro라고 해야 할 정도로 바이너리 파일 크기가 컸음

    • dte[1]라는 옵션도 있음. 유니코드 지원, CUA 키 바인딩 등 아주 심플하면서도 강력함. nano 대체 터미널 에디터로 만족중임 https://craigbarnes.gitlab.io/dte/

    • Windows에서는 "winget install zyedidia.micro"만으로 설치할 수 있음. 예전 8비트/16비트 시절 에디터 느낌임

  • MS같이 큰 조직에서 이런 프로젝트가 어떻게 승인되는지 정말 궁금함. 단순 개발자의 사이드 프로젝트인지, 제품 로드맵의 일부인지, 아니면 리더십 설득 과정이 있었는지 궁금함

    • 텍스트 에디터는 copilot 통합 공격 목표로 아주 적합함

    • 이유 설명에서 알 수 있듯, 명령줄에서 동작하는 에디터가 필요했음(윈도우 코어 서버 인스톨용), SSH로 접속해서도 써야 했고(몇 년 전부터 윈도우에 SSH 서버 기본 내장), vi 경험 없는 윈도우 관리자를 위한 모달 없는 에디터 필요성이 있었음. 이런 요구들이 이번 프로젝트로 이어진 것임

    • 각 팀이 뭔가 할당량을 채워야 해서 아이디어를 내기도 하고, 때로는 리더 지시에 의해(copilot 사용 등), 혹은 해커톤 같은 행사에서 시작해 확장되는 경우도 있음. 연구 조직에서 기술 인력이 손을 놓고 있으면 이런 게 나오기도 하고, 오랜 분석 끝에 그제야 예산 붙는 경우도 있음. 커미터 수만 봐도 꽤 전략적 투자였던 것 같음. 하루아침에 뚝딱 나온 프로젝트는 아님

  • 예전 EDLIN이 유니코드 지원으로 나와주길 기대함. EDLIN은 배치파일에서 스크립트적으로 키 입력을 파이프로 넣어서 특정 작업 자동화가 가능했음. 일종의 sed나 awk의 일부 대체품 같았음. vi도 비슷한 아키텍처가 된다고 생각하는데, 얼마나 비정상적인지는 별도 문제임

    • 아마 찾는 건 ed임. -s 옵션 붙이면 스크립트에 딱임

  • 관련 토론(271 포인트, 185개 댓글) https://news.ycombinator.com/item?id=44031529

답변달기