Microsoft Edit

 (github.com/microsoft)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Microsoft Edit는 단순한 편집 요구를 위한 에디터로, classic MS-DOS Editor에 경의를 표하면서 VS Code와 유사한 현대적 인터페이스와 입력 제어를 제공함
  • 목표는 터미널에 익숙하지 않은 사용자도 쉽게 사용할 수 있는 접근성 높은 편집기를 제공하는 것임
  • Windows는 WinGet, macOS는 Homebrew, Linux는 배포판 바이너리가 없거나 직접 빌드하려는 경우 설치 스크립트로 설치할 수 있음
  • Rust로 빌드하며, nightly Rust 설정은 바이너리 크기를 크게 줄이고 성능을 약간 개선하는 방식으로 권장됨
  • 패키지 관리자는 실행 파일 이름 충돌 가능성 때문에 edit 대신 msedit 이름을 권장받으며, 검색/바꾸기 기능에는 ICU 라이브러리 설정이 영향을 줌

Microsoft Edit의 목적과 성격

  • Edit는 “simple editor for simple needs”를 목표로 하는 단순한 편집기임
  • classic MS-DOS Editor에 경의를 표하면서도, 현대적 인터페이스와 VS Code와 유사한 입력 제어를 제공함
  • 터미널에 익숙하지 않은 사용자도 쉽게 사용할 수 있는 접근 가능한 에디터를 지향함

설치 방법

  • 바이너리는 Releases page에서 다운로드할 수 있음

  • Windows

    • 최신 버전은 WinGet으로 설치 가능함
    winget install Microsoft.Edit

  • Linux

    • 배포판이 바이너리를 제공하지 않거나 직접 빌드하려면 설치 스크립트를 사용할 수 있음
    • 필요 조건은 Rust, C 컴파일러, ICU, curl 또는 wget, tar임
    • 기본 설치는 msedit를 ~/.local/bin에 설치함
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh
    • 추가 플래그로 --dev는 main 브랜치에서 직접 빌드하고, --system은 /usr/local/bin에 설치함
    curl --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/microsoft/edit/… | sh -s -- --dev --system

  • macOS

    • 최신 버전은 Homebrew로 설치 가능함
    brew install msedit

빌드 방식

  • 빌드에는 Rust 설치와 저장소 클론이 필요함
  • nightly Rust를 사용하는 경우 다음 명령으로 release 빌드함 
    cargo build --release --config .cargo/release.toml
  • stable Rust를 사용하는 경우 RUSTC_BOOTSTRAP=1 환경 변수를 설정하고 nightly 빌드 지침을 따르는 방식이 권장됨
    • 이 방식은 바이너리 크기를 크게 줄이고 성능을 약간 개선함
  • 별도 설정 없이 stable Rust로 빌드하려면 다음 명령을 사용함 
    cargo build --release

빌드 구성 옵션

  • 빌드 시 환경 변수로 구성을 조정할 수 있음
  • EDIT_CFG_ICU*는 ICU 라이브러리 이름 설정과 관련되며, Linux 패키지 관리자는 이 옵션 검토가 권장됨
  • EDIT_CFG_LANGUAGES는 빌드에 포함할 언어 목록을 쉼표로 지정함

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

  • 표준 실행 파일 이름은 edit이고 대체 이름은 msedit 임
  • 기존 명령과 edit 이름이 충돌할 수 있어, 패키지와 실행 파일 이름은 msedit를 권장함
  • ms-edit 같은 이름은 피해야 함
  • 가능하다면 edit 별칭을 할당하는 방식이 권장됨

ICU 관련 설정

  • 이 프로젝트는 검색과 바꾸기 기능을 위해 ICU 라이브러리에 선택적으로 의존함
  • 기본적으로 플랫폼별 ICU 라이브러리 이름을 찾음
    • Windows: icuuc.dll, icuin.dll
    • macOS: libicucore.dylib
    • Linux 및 기타: libicuuc.so, libicui18n.so
  • 설치 환경의 SONAME이 다르면 빌드 시 환경 변수를 설정해야 함
    • EDIT_CFG_ICUUC_SONAME: 예 libicuuc.so.76
    • EDIT_CFG_ICUI18N_SONAME: 예 libicui18n.so.76
  • ICU 심볼은 기본적으로 _ 접두사와 버전 접미사 없이 u_errorName 같은 형태로 export된다고 가정함
  • 다른 심볼 형태를 쓰는 환경에서는 추가 환경 변수를 사용할 수 있음
    • EDIT_CFG_ICU_CPP_EXPORTS=true: _u_errorName 같은 C++ 심볼을 찾으며, macOS에서는 기본 활성화됨
    • EDIT_CFG_ICU_RENAMING_VERSION=76: u_errorName_76 같은 심볼을 찾음
  • EDIT_CFG_ICU_RENAMING_AUTO_DETECT=true를 설정하면 실행 파일이 런타임에 renaming version 값을 감지하려고 시도함
    • 이 방식은 ICU가 공식 지원하지 않으므로 의존하지 않는 것이 권장됨
    • UNIX에서는 macOS를 제외하고 다른 옵션이 없을 때 기본 활성화됨
  • 빌드 설정 테스트는 cargo test에 --ignored 플래그를 붙여 실행함 
    cargo test -- --ignored

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 글이 일주일에 세 번이나 올라올 정도로 관심이 컸음

    1. 작성자 본인 - https://news.ycombinator.com/item?id=44034961
    2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892
      그리고 이번 글

  • 이 에디터의 대상 사용자층에게 예전에는 micro를 추천했는데, 이제 바꿔야 할지 궁금함

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

    • 바꿀 필요는 없어 보임
      edit는 적어도 바로 써봤을 때 구문 강조도 기본 지원하지 않았음
    • 마지막으로 확인했을 때 micro는 바이너리 크기만 보면 macro라고 불러야 할 정도였음
    • dte도 있음. 같은 지점을 정확히 겨냥하면서 Unicode 지원, CUA 키 바인딩 등 더 많은 기능을 갖춘 아주 가벼운 에디터임
      nano 대신 터미널 에디터로 쓰고 있음
      [1]: https://craigbarnes.gitlab.io/dte/
    • Micro는 nano 같은 것을 대체하기에 훌륭한 에디터임. 다만 edit의 대체재로는 좋지 않을 것 같고, edit는 아주 기본적인 반면 micro는 Lua로 꽤 확장 가능함
      큰 파일도 꽤 잘 다룸
    • Windows에서도 "winget install zyedidia.micro"만으로 설치 가능함. 비슷한 시대의 8비트·16비트 에디터들이 떠오름

  • Microsoft 규모의 조직에서 이런 프로젝트가 어떻게 승인되는지 진짜 궁금함. 몇몇 개발자의 사이드 프로젝트인지, 아니면 제품 로드맵의 일부인지 궁금함
    리더십에게 여기에 시간을 쓰자고 어떻게 설득했을까?

    • 설명대로라면 Windows Core 서버 설치에서 동작하는 명령줄 텍스트 에디터가 필요했음
      Windows에 SSH Server가 포함된 지 꽤 돼서 SSH만으로도 완전히 관리할 수 있고, vi 경험이 없는 Windows 관리자도 쓸 수 있는 모드 없는 에디터가 필요했던 것임
    • 텍스트 에디터는 Copilot 통합 대상으로 너무 자연스러움
    • 각 그룹은 뭔가를 해야 하고 아이디어를 내게 됨. 어떤 때는 “Copilot을 써라” 같은 리더십 방향에서 나오고, 어떤 때는 hackerdayz 같은 행사 아이디어가 확장됨
      연구 조직에서 기술 인력들이 여유를 갖고 시작하는 경우도 있고, 깊은 분석과 여러 반기를 거쳐 자금을 받는 경우도 있음
      여기 기여자 수를 보면 이 프로젝트는 아마 전략적 투자였을 가능성이 큼. 하룻밤 사이에 나온 것은 아님

  • DOS 6.22와 이후 7.0, 즉 Win95 무렵의 원래 edit.com은 내 첫 IDE였음. qbasic으로 시작해서 비슷하거나 같은 인터페이스에 익숙했고, djgpp로 C/C++를 배울 때도 계속 edit.com을 썼음
    내 “프로젝트 파일”은 edit file1.cpp file2.cpp file3.cpp가 들어간 e.bat였고, Alt-1,2,3으로 쉽게 전환되는 꽤 괜찮은 다중 파일 지원이 있어서 썼음. 지금도 에디터 키 바인딩을 Alt/Cmd-1,2,3으로 파일 전환하도록 다시 매핑하고, “활성 세트”를 앞쪽 몇 개 파일로 작게 유지하려고 함
    구문 강조도 없고 들여쓰기 동작도 아주 좋지 않아 훌륭한 코드 에디터는 아니었음. 그래서 커리어 초반에는 손으로 치기 쉬우면서 탭 같지 않은 공백 두 칸 들여쓰기를 썼음. 그래도 코드에 바로 닿아 있는 느낌은 강했음
    다른 사람들이 qedit 같은 에디터를 많이 쓴다는 건 알았지만 이상하게 잘 맞지 않았고, Unix식 에디터들도 DOS에서는 어색했음
    잠깐 써보니 여러 버퍼를 지원하는 것 같긴 해도 같은 키 바인딩으로 버퍼 전환은 안 되는 듯함

    • 그런 건 이슈로 올리는 게 좋음. 이런 사항은 초기에 들어가면 반영될 가능성이 있음
      그리고 단순히 비슷한 게 아니라 문자 그대로 같았음. EDIT.COM은 특수 플래그로 QBASIC을 실행했을 뿐이고, QBASIC을 그 플래그와 함께 직접 실행할 수도 있었음. https://news.ycombinator.com/item?id=44037509에서 말했듯이, 재미로 실제로 그렇게 해봤음
    • 구문 강조는 없었지만, 더 나은 표현이 없어서 말하자면 구문 대문자화는 있었음
      한 줄을 전부 소문자로 입력하고 엔터를 치면 예약어를 자동으로 대문자로 바꿔줬음. 대단하진 않았지만 도움이 됐음
    • copy con 시절 뒤에 나온 edit는 정말 구세주였음

  • 마음에 드는 점이 많음. 우선 의존성 목록이 비어 있음이라니, 그걸로 이미 설득됨
    아주 잘 동작함. 파일 브라우저와 대화상자까지 갖춘 TUI를 이걸 위해 통째로 만들었다는 게 믿기지 않음. 내 프로젝트에도 쓰고 싶은데 얼마나 쉬울지 궁금함. 프로젝트 관련자가 여기 있다면 왜 Ratatui를 쓰지 않았는지도 궁금함
    코드 품질도 최고 수준이고, 한마디만 할 수 있음: Bravo!

    • 테스트를 쉽게 해주는 몇몇 개발 의존성을 빼면 말 그대로 의존성이 없음
      Windows 같은 운영체제에서 관리자가 쓰는 기본 도구로 배포하는 물건이라면 합리적인 선택임. “직접 만들기” 관련 배경은 lhecker의 답변을 보면 더 알 수 있음
      [1]: https://news.ycombinator.com/threads?id=lhecker

  • 한 달쯤 전에 Microsoft가 Windows 사용자들이 더 익숙하게 느끼도록 자체 Linux 배포판을 갖고 있다는 얘기를 들었음. 기억으로는 꽤 단순한 GNOME 구성이라 특별할 건 없었음
    Microsoft가 bash 대신 PowerShell을 넣고, vim·nano 같은 선택지와 함께 Edit를 넣고, 개발자 설치에는 .NET과 Visual Studio Code를 포함하는 Microsoft 전용 Linux 배포판을 만들 기회를 쓰지 않은 게 의외임
    이걸 기본 WSL 설치로 삼을 수도 있었음. Ubuntu나 Debian 같은 전형적인 배포판과의 전쟁에서 이기진 못했겠지만, Windows 사용자는 많으니 일정 비중을 얻고 흔한 선택지가 될 수 있었음
    Microsoft는 Linux 커널을 지배할 수는 없지만 사용자 영역은 장악할 수 있음. 자사 애플리케이션이 인기 배포판에 기본 설치되는 흐름을 만들었다면 어땠을지 상상해볼 만함
    Microsoft Edit도 PowerShell 등과 마찬가지로 Linux에서 쓸 수 있음. 10년 전쯤 카드를 잘 썼다면, 많은 Windows 사용자가 WSL로 쓰는 덕에 그들의 배포판이 지금 상위 5위 안에 들었을 수도 있음
    거대 기업은 개인 공간에 자기 흔적을 밀어 넣을 수 있음. 이제 Microsoft Edit에 Co-Pilot만 기본으로 켜지면 됨

    • 시간이 지나면 Microsoft가 Linux로 옮겨갈 가능성이 크다고 봄. 적어도 Windows Server와 임베디드 Windows 쪽은 그렇고, 이후 Windows 데스크톱도 점진적으로 바뀌거나 Windows Legacy와 Windows “Linux Workstation” 같은 선택지로 나뉠 수 있음
      Linux 커널에 일종의 “슈퍼” WINE을 얹고, 특정 프로그램에는 가상 머신에서 긴밀히 통합된 고전 Windows를 fallback으로 제공하는 식일 수 있음
      다만 문제는 NT 커널이 설계 면에서 Linux 커널보다 나은 부분이 많다는 것임. 예를 들어 NT 커널은 GPU 드라이버가 완전히 죽어도 복구할 수 있는데, Linux는 그런 상황을 꽤 힘들어할 것 같음. 다른 드라이버도 비슷함
      하지만 Windows는 Microsoft에 점점 자산보다 부채가 되어가고, 특히 서버 영역에서 그렇음. 주요 매출원은 Azure와 Office 365이고 여전히 두 자릿수 성장 중인 반면 Windows 라이선스 성장은 정체 상태임
      최소한 Linux 기반 Windows Server와 Linux 기반 Windows Workstation 같은 버전은 나올 것 같음
    • WSL이 존재하는 이유는 기업 개발자들이 Linux를 실행할 방법이 필요했기 때문임
      IT 지원과 기술 지원 담당자들은 보통 Linux를 잘 모르고 지원하기도 싫어함. WSL은 이 문제를 해결함
      대부분의 개발자는 Linux 자체를 쓰고 싶어 하지 않음. 많은 개발자는 터미널 사용법도 제대로 모르고 GUI 도구에 의존함
    • Microsoft가 전용 Linux 배포판을 만들지 않은 게 의외라면, 마지막 시도는 그렇게 잘되지 않았음. 이름은 Xenix였음
    • 이름 인지도가 도움이 된다고 봄. 개발자는 들어본 적 없는 배포판은 설치하고 싶어 하지 않지만 Ubuntu는 설치하고 싶어 함
      WSL이 Ubuntu를 지원하면 그 인지도를 활용할 수 있음
    • Microsoft의 1차 Linux 배포판인 Azure Linux(구 CBL-Mariner)와, 사람들이 오래전부터 만들어온 Windows처럼 보이는 Linux 데스크톱 환경 스킨을 혼동한 듯함
      Azure Linux는 컨테이너, VM, 서버 등에 쓰기 위한 Microsoft 지원 운영체제임

  • 이건 그냥 “해보고 싶어서” 만든 프로젝트처럼 보임. 나도 무슨 일이 벌어지는지 이해하려고 그런 걸 많이 해봐서 이해는 됨
    하지만 Turbo Vision을 FPC로 다시 쓰고 여러 타깃으로 컴파일하는 작업은 20년 전부터 있었음. Turbo Vision은 아마 존재하는 최고의 텍스트 모드 윈도잉 라이브러리임
    재미있는 부분은 텍스트 화면 전체를 이런 배열에 매핑할 수 있을 때 시작됨:
    var
    Screen: Array[1..80,1..25] Of Byte Absolute $B800; // or something like that as i recall
    Turbo Vision이 가져온 건 이동 가능한 모달/비모달 창이었음. 기본적으로 그 배열을 루프에서 계속 다시 쓰는 구조였고, 꽤 빠릿했음. 그 라이브러리로 돈을 엄청 벌었음

    • 궁금한 사람들을 위해, Unicode도 지원하는 현대적인 C++ Turbo Vision 포트가 있음:
      https://github.com/magiblot/tvision
    • 이건 “해보고 싶어서” 만든 프로젝트가 아님. Windows에 포함되고 SSH 너머에서도 동작하는 작은 TUI 에디터가 필요했던 것임
      https://news.ycombinator.com/item?id=44034961
    • 정확히는 array[1..25, 1..80] of Word absolute $B800:0000임
      TP의 배열은 행 우선 순서로 배치됐고, 각 문자는 두 바이트로 표현됐음. 하나는 문자 자체, 다른 하나는 속성(전경/배경색과 깜빡임)이었음
      그래서 더 낫게 쓰면 array[1..25, 1..80] of packed record ch: char; attr: byte end absolute $B800:0000임
      Hercules 같은 흑백 텍스트 디스플레이(모드 7)에서는 $B800을 $B000으로 바꾸면 됨
    • Turbo Vision으로 어떻게 돈을 벌었는지 궁금함. 괜찮다면 공유해줬으면 함
    • 새로운 현대적 TUI 프레임워크를 볼 때마다 실망은 똑같음. “아, 이건 Turbo Vision만큼 좋지 않네”

  • 이제 Unicode 지원 EDLIN을 기다리고 있음
    배치 파일에서 표준 입력으로 키 입력을 파이프해 넣어 어떤 편집 작업을 스크립트화할 수 있었던 걸 기억함. sed나 awk의 일부 기능을 대신하는 느낌이었음
    해보진 않았지만 vi로도 가능할 것 같음. 그게 아주 저주받은 방식인지 아닌지는 별개임

    • 찾는 건 아마 ed일 것 같음. 경우에 따라 -s와 함께 쓰면 됨

  • 재미있음. 솔직히 누가 쓰라고 만든 건지는 잘 모르겠지만, 재미있어 보임

    • Windows Terminal에서 파일을 편집하고 싶은 사람들을 위한 것임. 예전 edit 명령은 2006년 이후 Windows에서 지원되지 않았으니, 그 뒤로 명령줄에서 쓸 수 있는 Microsoft 제공 에디터가 없었음
      이 에디터가 얼마나 빠른지 인상적임. https://github.com/microsoft/edit/pull/408

      줄바꿈 검색에 특화된 SIMD 루틴을 작성하면 [125GB/s까지] 끌어올릴 수 있음

    • README에 바로 적혀 있음:

      목표는 터미널에 거의 익숙하지 않은 사용자도 쉽게 쓸 수 있는 접근성 좋은 에디터를 제공하는 것이다

    • Notepad보다 훨씬 큰 개선임
    • LSP 지원이나 ripgrep 기반 검색이 있거나 생기면 vim을 기꺼이 대체할 수 있음
      지금은 Helix를 쓰고 있지만 좋은 TUI가 마음에 듦
    • vi가 싫어서 터미널에서 nano를 대체할 더 제정신인 물건을 찾는 나 같은 사람을 위한 것임

  • 1993년에는 edit로 바이너리 파일을 열고 하트 모양이 보이는 걸 즐기곤 했음

    • 그 경험, DOS defrag 시각화, 그리고 세이브 파일을 직접 헥스 편집하던 일이 내가 지금 개발자가 된 이유에 거의 해당함
답변달기