기본적인 Windows OS의 키보드 단축키가 동작하지 않는 부분을 언급하고 싶음. 예를 들어 ALT+F로 파일 메뉴를 여는 기능이나 ALT+SPACEBAR로 시스템 컨텍스트 메뉴(최대화, 최소화, 닫기 메뉴 등)를 띄우는 것도 동작하지 않음. DirectX 렌더링 백엔드 특성상 애플리케이션이 네이티브 win32 프로세스보다는 비디오 게임처럼 렌더링되는 것 같음. 설치 후 디렉토리 용량이 400MB가 넘는 것도 놀랄 만함. VSCode가 380MB 정도임을 생각하면, Electron 앱이 아니라는 건 믿겠지만 무얼 이리 많이 넣었는지 궁금함. Rust 앱이 원래 가벼운 줄 알았으나, 설치 사이즈가 Java 수준의 바이너리/의존성 비대화에 근접한 느낌임
Rust의 Hello World 바이너리가 Git보다 큼. 그래도 Java나 Electron보다는 작지만, 딱히 작다고 할 수는 없음
PSPad는 40MB이고, 아직까지도 업데이트되는 레거시 소프트웨어임. Notepad++는 17MB임. 최신의, 컴파일된 최고의 Rust 프로젝트가 400MB를 차지한다는 건 말도 안 된다고 생각함
400MB가 넘는 설치 용량의 비대함은 많은 사람들에게 불쾌감을 줄 수 있음. 이 용량이 왜 필요한지 빠르게 설명할 필요가 있음
Electron이 아니라고 해도, Electron의 절반인 Node.js가 기본적으로 포함된 느낌임. 대부분의 LSP가 .js 기반이고, 확장 기능이 WASM임. VSCode는 확장 기능을 별도의 설정 디렉토리에 두지만, Zed는 설치 디렉토리에 다 들어 있음
참고로, 한 창에서 그래픽 컨텍스트와 Win32 메뉴바를 동시에 갖는 것도 가능함
Zed가 서브픽셀 폰트 렌더링을 구현했는지 궁금함. 예전에 UI 렌더러를 Mac의 HiDPI 디스플레이에 맞게 설계해서, LoDPI 디스플레이를 사용하는 리눅스(그리고 윈도우) 사용자는 흐릿한 폰트로 고통받았던 기억이 있음
서브픽셀 렌더링은 모르겠지만, 최근 패치 이후 리눅스의 폰트 렌더링이 상당히 좋아졌음 관련 링크
이 부분이 궁금함. Zed도 Mac에서는 CoreText, 윈도우에서는 DirectWrite를 사용하는 걸로 알고 있음. CoreText가 모든 걸 처리해주지 않나?
윈도우 빌드는 DirectX 11로 렌더링하고, 텍스트는 DirectWrite로 처리해서 윈도우 감성을 살림. DirectWrite 폰트 렌더링이 윈도우의 서브픽셀 렌더링을 사용함. 내 모니터에서는 (리눅스보다) 괜찮아 보였음. 이런 문제를 미리 고려해 잘 설계한 것 같음
macOS에서 1440p 외부 모니터를 사용하는데, 폰트가 정말 끔찍했음. 랩탑의 Retina 디스플레이에선 괜찮은데 외부 모니터에선 너무 흐릿해서 두통이 올 정도였음
나도 1440p 모니터에서 다양한 폰트로 테스트했는데 보통 수준임. 하지만 이건 Zed의 문제가 아니라 윈도우 자체의 폰트 렌더링이 원래 별로여서 그렇다고 생각함. VSCode도 마찬가지임. 고퀄리티 폰트 렌더링을 원하면 4K 이상의 화면이 정답인 것 같음
수개월 동안 Zed를 주력으로 썼는데, 최근 다시 VSCode로 돌아옴. 이유는 둘인데, 하나는 내 실수고 하나는 어디에 문제가 있는지 확실치 않음. 1. 밤 늦게까지 코딩하다가 파일을 체크인 전에 이름을 바꾼 다음, 새 버전을 실수로 삭제해서 몇 시간치 작업을 날려버림. Zed의 우클릭 메뉴에 "Delete"와 "Trash"가 바로 붙어 있는데, Delete는 휴지통 통과 없이 바로 삭제됨. Ctrl+Z도 아직 구현 안 되어 있어서 백업 없으면 복구 불가임(버전 컨트롤에도 아직 안 올림). 2. Rust 워크스페이스에서 특정 crate의 에러·워닝 표시가 에디터에 전혀 안 나왔음. 이것저것 설정 만져보다가 안돼서 VSCode 켰더니 별다른 설정 없이 잘 됨
macOS 터치바 쓸 때 생각남. 커밋 관리 메뉴에서 "Cancel"이 "Force Push" 옆에 있었음
Zed에 Ctrl+Z가 안 된다는 점이 믿기 힘들 만큼 중요한 기능의 부재임
이렇게 기본 기능이 없는 에디터를 어떻게 써야 하는지 의문임. 어떤 장점이 있는 건지 궁금함
Zed는 정말 멋지게 보이고 실제로 <i>느낌</i>도 끝내줌. 리눅스에서 잠깐 써 봤는데 이 에디터의 느낌은 직접 경험해보지 않으면 설명하기 힘듦. GPU 가속 에디터의 차별성을 쉽게 간과할 수 있는데, 직접 써보면 반드시 반하게 됨. 내가 Zed로 완전히 못 옮기는 유일한 이유는 아직 DevContainer 지원이 없기 때문임. devcontainer 설정을 엄청 공들여 세팅해놨기 때문에, 이걸 버리고 로컬에 툴과 라이브러리, 설정을 다 다시 설치하는 건 너무 후퇴로 느껴짐. 이 기능을 기다리는 사람이 많으니, 언젠가 지원될 것으로 기대함 관련 이슈
커스텀 DevContainer에 대해 더 자세히 이야기해줄 수 있나 궁금함
DevContainer가 어떤 점에서 도움이 되는지 알고 싶음. 내 환경을 세세하게 문서화하긴 하겠지만, 그 이상 어떤 이점이 있는지 궁금함
devpods와 호환됨
에디터의 메모리와 CPU 사용량이 내가 작업하던 웹앱 브라우저 탭보다 적다는 점이 정말 신선함. 지금까지 매우 만족함
zed가 lsp 실행에 node도 띄우니 확실히 확인하고 쓰는 게 좋음
바이너리 크기가 0.5GB 수준이라, 브라우저처럼 특별히 가볍다는 느낌은 아님
Zed를 데일리 드라이버로 사용하려 했으나 TypeScript 경험이 기대 이하였음. 에디터 자체는 빠르지만 "jump to declaration"같은 LSP 액션이 우리 코드베이스에서는 VSCode/ Cursor 대비 매우 느렸음
typescript-go를 LSP로 지원하는지 확인해보길 추천함. IDEA에서 최근 추가됐고, 몇 개월간 써봤는데 정말 환상적임
나도 같은 경험, 같은 결론임. Zed는 편집 속도는 빨랐지만 고급 기능들이 느려서, 결국 전체적으로 VSCode보다 체감 속도가 느렸음
둘 다 tsserver를 내부적으로 쓰는 걸로 아는데, 왜 느린지 이해가 안 됨
Electron은 NodeJS를 v8 pointer compression과 함께 빌드해서 메모리 사용을 최대 50% 줄이고 속도도 올려줌
괜찮지만, 나는 이미 리눅스로 넘어갔고 Zed도 그 환경에서 아주 잘 돌아가고 있음
[Window Title]
Critical
[Main Instruction]
Unsupported GPU
[Content]
Zed uses DirectX for rendering and requires a compatible GPU.
Currently you are using a software emulated GPU (Microsoft Basic Render Driver) which
will result in awful performance.
For troubleshooting see: https://zed.dev/docs/windows
Set ZED_ALLOW_EMULATED_GPU=1 env var to permanently override.
[Skip] [Troubleshoot and Quit]
아쉽게도 이런 이슈가 발생했음
이건 사실 Zed의 문제가 아니라 시스템 이슈임. 요즘 DirectX 안 되는 환경 찾기 힘든데, 혹시 VM에서 윈도우 돌리는 중인지 궁금함
텍스트 에디터가 소프트웨어 렌더링에서 도대체 무슨 짓을 하길래 "끔찍한 성능"까지 나오는지 궁금함
Zed는 정말 멋짐. 내가 원하는 건 다 할 수 있음. 필요한 걸 쉽게 찾을 수 있고, 정말 빠름. ACP 모드에서 IDE에서 CLI 터미널을 포크할 수도 있음. 이렇게 되면 Cerebras나 Qwen code 480b 같은 엄청 스마트한 CLI 에이전트를 저렴하고 강력하게 쓸 수 있음
오래 기다렸는데 여전히 x86_64 바이너리만 있음. ARM Surface Pro를 정말 좋아해서, Zed가 이 하드웨어에서 돌아가면 정말 좋을 것 같음. Zed 팀에서 이 댓글을 보면 꼭 생각해줬으면 좋겠음
나는 직접 소스 빌드해서 Windows aarch64에서 돌림. 16GB Surface Pro에서 빌드가 꽤 느리긴 해도 문제없이 잘 됨. 공식 바이너리도 기대함
어떤 이유인지 모르지만, Windows에서 msvc로 zed를 빌드하면 리눅스에 비해 굉장히 느리게 느껴짐. 관련 이슈까지 열렸음
Hacker News 의견
아쉽게도 이런 이슈가 발생했음