GN⁺: 나쁜 소식, Emacs

Emacs 30 버전의 문제점과 포크 버전의 생성

• Emacs의 마스터 브랜치가 중대한 변경으로 인해 사용자와 개발자들의 우려에도 불구하고 손상됨.
• 해당 변경으로 인해 Emacs 레지스터와의 상호작용이 불편해지고, 간단한 작업에도 추가적인 키 입력이 요구됨.
• 개선된 포크 버전을 만들어 사용 및 개발 중이며, 관심 있는 사람들의 참여를 환영함.

Emacs 마스터 브랜치의 안정성과 최근의 변화

• Emacs 마스터 브랜치는 개발 버전으로, 최신 개발 사항을 경험하고자 하는 사용자들이 추적함.
• 최근 몇 년간 Emacs 유지보수자들의 노력으로 마스터 브랜치는 매우 안정적이었음.
• 그러나 최근 변경으로 인해 사용자들이 불쾌한 놀라움을 경험함.

사용자 경험의 저하와 커뮤니티의 반응

• 새로운 변경으로 인해 사용자 경험이 저하되었으며, 이전의 효율적인 동작을 선택적으로 복원할 것을 요청하는 목소리가 커짐.
• 커뮤니티 구성원들의 명확한 의견에도 불구하고, 변경을 옹호하는 개발자의 태도로 인해 문제가 해결되지 않음.
• 유지보수자들은 사용자 경험을 희생하면서도 변경을 고수하는 태도를 보임.

새로운 포크 버전의 개발과 사용자의 자유

• 사용자의 자유를 중요시하는 저자는 기존 Emacs의 이상한 변경을 강요받는 것을 거부하고 새로운 포크 버전을 생성함.
• 이 포크 버전은 마스터 브랜치에서 좋은 변경 사항만을 선택적으로 가져오며, 저자의 개발로도 개선됨.
• 포크 버전에 관심이 있는 사람들은 저자의 저장소에서 클론할 수 있으며, 협업과 제안을 환영함.

GN⁺의 의견

이 글에서 가장 중요한 것은 Emacs 30 버전에서 발생한 사용자 경험의 저하와 이에 대한 커뮤니티의 반응입니다. Emacs는 오랫동안 개발자들 사이에서 맞춤화와 확장성으로 사랑받아왔기 때문에, 이러한 변화가 사용자들에게 어떤 영향을 미칠지에 대한 관심이 높습니다. 또한, 한 개발자가 커뮤니티의 의견을 무시하고 자신의 변경을 강행하는 과정은 오픈 소스 프로젝트에서의 의사결정과 협업 문화에 대한 흥미로운 사례를 제공합니다. 이 글은 사용자들이 소프트웨어의 변화에 어떻게 반응하고, 필요에 따라 자신만의 해결책을 찾아가는 과정을 잘 보여주고 있습니다.

[neo]

Hacker News 의견

• Emacs 개발 브랜치에서 중대한 변경이 발생하고 일부 사용자들이 우려를 표현할 때, 그 변경은 즉시 되돌려지지 않음. 장단점이 토론되고, 다양한 해결책이 구현 및 개선되며, 마침내 타협점을 찾음.

  • 사용자들의 우려 제기는 3일 전부터 시작됐으며, 이 과정이 이미 결론지어진 것은 아님.
  • Eli의 최근 메시지에서는 새로운 행동이 기존 것보다 훨씬 합리적이라는 두 사람 간의 초기 토론을 언급하며, 이제 다른 의견이 제시된 후에야 행동 기준에 대해 논의 중임을 밝힘.

• Emacs에서 복사(또는 "레지스터"라고 더 일반적으로 불리는 기능)의 작동 방식을 변경하는 커밋이 최근 수락됨. 이제 Emacs는 발생하는 일을 보여주는 미니버퍼를 열고, 사용자가 Enter 키를 눌러 변경을 수락하도록 요구함.

  • 이는 기본 동작을 변경하고, 쉽게 구성할 수 없을 가능성이 있으며, 충분한 논의 없이 이루어진 것으로 보임.
  • Vim 사용자에 대한 비유를 통해 이 변경이 얼마나 불편한지 설명하고, 이 문제를 제기하려 했던 OP의 노력과 개발자 Thierry의 반응을 서술함.

• 메일링 리스트를 검토한 결과, 이 행동을 되돌릴 수 있는 옵션이 있을 것으로 보임.

  • 이 옵션은 원래 글이 게시되기 전에 언급되었지만, 글쓴이가 이를 보지 못했을 수도 있음.
  • 이 옵션이 문제를 해결할 것으로 예상되지만, ginko의 답글에 따르면 여전히 Enter 키 입력이 필요할 수 있음.

• Emacs에서는 근육 기억을 중요한 고려사항으로 여겨야 함.

• 개발자의 입장에서는 안정성을 원하는 사용자들은 릴리스 브랜치를 사용하거나 마스터에서 커밋을 고정해야 함. 개발 브랜치는 진행 중인 기능을 개발하기 위해 사용되며, 때때로 이러한 변경이 자주 발생할 수 있음.

• 글쓴이의 태도는 다소 고집스럽고, 이 기능을 사용하는 사람이 매우 적음을 지적함. 무급 유지보수자가 먼저 상의하지 않고 약간 변경한 것이 마스터 브랜치를 "파괴"하는 것으로 간주되어서는 안 됨.

• Emacs를 떠난 지 20년이 지났지만, 이 변경이 상당히 혼란스러운 것으로 이해됨. "주방 싱크대"로 자부하는 Emacs가 기존 행동으로 되돌릴 수 있는 옵션을 추가하지 않은 이유를 이해하지 못함.

• Emacs의 핵심은 매우 사용자 정의가 가능한 플랫폼이라는 점이며, 어떤 기능의 동작이 마음에 들지 않으면 몇 줄의 Lisp 코드로 직접 수정할 수 있음. 한 가지 기능의 변경으로 인해 전체 프로젝트를 포크하는 것은 말이 되지 않음.

• Emacs의 또 다른 포크/재구현을 시도하는 것이 유일한 해결책으로 보임. 이번에는 분명 성공할 것이며, 다른 모든 것들처럼 전혀 관련이 없지 않을 것임.

• 이 변경에 대한 "다른 쪽"의 주장은 무엇인가? 이러한 의견이 있는 변경은 보통 변경 뒤에 합리적인 이유가 있음. 혹은 그렇지 않을 수도 있음.