빠른 터미널에 대해 내가 틀렸던 것

커뮤니티와 아이디어 교환의 힘을 보여주는 좋은 후속 글이라, 인터넷을 조금 더 인간적으로 느끼게 해줌

오류를 인정하고 고치는 일이 가능하다니 놀랍다는 반응이 먼저 나옴
진지하게는, 여러 새 셸을 별로 좋아하지 않아 첫 글은 넘겼지만 이번 글은 좋았음. ash는 기본 히스토리 동작이 내 사용 방식과 맞지 않고, fish 같은 셸은 관심 없는 UI 기능이 과하다고 느꼈음
다만 자동 프롬프트 캐시처럼 보이는 기능은 좋아 보임. 직접 괴물 같은 프롬프트를 만들고 허술하게 캐싱해본 적이 있어서 더 와닿음

이런 글이 좋음. 더 많은 사람이 실수와 후속 정정을 공개하면 인터넷이 조금 더 인간적인 공간이 됨

작성자임. 고맙고, 특히 팀에 본보기가 되기 위해 실수 인정을 꾸준히 하려고 노력함

첫 글을 보고 이미 zshrc를 최적화해서 시간을 절반으로 줄였음. 이후 더 찾아보다가 zsh-bench도 썼고, 그 글이 최적화 계기가 되어줌

더 이상 유지보수되지는 않지만 zsh4humans는 성능 면에서 최첨단에 가까움. 만든 사람이 일종의 Zsh 천재 같음
직접 쓰지는 않는데, 통제권을 유지하고 싶기 때문임. 그래도 이해할 수 있는 부분에서는 transient prompt 같은 아이디어를 가져다 썼음 zsh-bench도 같은 작성자의 프로젝트인 줄은 몰랐음

좋은 팁임. zsh4humans 프로젝트에 진짜 보석 같은 부분이 있어 보이니 확인해보겠음

zsh-syntax-highlighting이 매 키 입력마다 전체 버퍼를 다시 강조해서 지연을 만든다는 부분이 실제로 눈에 띄는지 궁금함
코드 편집기에서도 본질적으로 비슷한 일을 하는데 지연을 거의 못 느꼈음. 명령줄은 편집기 기준으로 보면 “긴” 명령도 대체로 짧으니 문제가 생긴다는 게 의외임
다만 구문 강조가 생각보다 훨씬 복잡하다면 그럴 수도 있겠음

이 글에서 새 요령을 많이 배움. 지금까지는 프롬프트에 들어가는 데이터가 느린 백엔드에서 오지 않게 하는 정도의 단순한 수정만 해왔음
여기에는 훨씬 더 세밀한 프롬프트 최적화가 들어 있고, 터미널을 셀 수 없이 많이 여는 일상 흐름에서는 이런 작은 개선이 누적되어 큰 영향을 줌