NeoVim은 왜 사용자의 undo 데이터를 삭제했는가

"They had no concept of a duty of care to their users."

NeoVim은 왜 사용자의 undo 데이터를 삭제했는가

컴퓨터 과학자 David Chisnall은 2000년부터 vim을 사용하며 persistent undo 기능에 의존해 왔다. NeoVim을 처음 써봤을 때 undo가 작동하지 않았고, vim에서도 undo 파일이 사라진 것을 발견했다. NeoVim이 vim의 undo 파일 형식을 바꾸면서 기존 파일을 삭제했기 때문이다. 이슈를 제기했지만 "persistent undo 형식은 불안정하니 데이터 보존을 기대하지 말라"는 답변을 받았다. 저자는 이를 두고 NeoVim 개발자들에게 사용자에 대한 주의 의무가 없다고 비판한다.

"persistent" undo라는 이름의 기능에서 데이터 보존을 기대하지 말라는 태도는, 단지 파일 시스템에 있는 데이터 파일이라는 이유로 프로그램이 그것을 삭제해도 된다는 발상이며, 이는 그들에게 사용자에 대한 주의 의무라는 개념이 전혀 없었음을 보여준다.
  1. jeremyjh

    이 이야기에는 작성자의 사건 버전을 뒷받침하는 참고 자료가 없지만, 다음과 같은 점은 상당히 사실인 것으로 보입니다:

    1. 이 변경은 Neovim과 Vim 모두의 undo 기록을 깨뜨릴 것입니다 [편집: 실제로는 그렇지 않습니다]

    2. 이는 Neovim이 다른 사용자의 컴퓨터에서 다른 프로그램이 만든 데이터를 삭제한다는 의미입니다.

    3. 이는 기능이 출시되기 전에 알려져 있었습니다.

    4. 그럼에도 불구하고 그들은 그렇게 했습니다.

    이에 대한 사후 정당화는 정말 있을 수 없다고 생각합니다.

    https://github.com/neovim/neovim/pull/13973#issuecomment-789...

    편집: 중요한 세부 사항을 놓쳤습니다. 사용자가 nvim과 vim 모두에서 undodir에 대해 동일한 경로를 지정했습니다. Vim은 기능을 활성화하려면 경로가 필요합니다. 공유 기본 경로는 없습니다. 사용자가 경로를 공유한다는 점은 제 관점에서 이야기를 상당히 바꿉니다. 왜냐하면 이제 이것은 nvim이 데이터 마이그레이션을 작성하는 대신 nvim이 만든 데이터를 삭제하는 경우이기 때문입니다.

    여전히 이에 동의하지 않을 수 있지만, 최소한 "다른 경로를 사용하라"와 같은 대안을 더 복잡하게 만들고 이 상황에 대한 제 해석을 완전히 바꿉니다. 이 맥락에서 Neovim의 결정은 정당화될 수 있다고 생각합니다. 아마도 그들은 이전 undo 폴더의 내용을 어딘가에 저장하고 사용자에게 알렸을 수 있습니다. 틀림없이 그것이 더 공감적일 것입니다. 그들이 이것을 할 도덕적 의무가 있었다는 데에는 별로 동의하지 않습니다.

  2. gavinhoward

    Neovim 사용자로서, 이것은 고통스러운 깨달음으로 저를 멈추게 했습니다: 저도 같은 일을 겪었지만 몰랐을 수 있습니다. 한때 무언가를 undo할 수 없었던 적이 있었는데, 그것은 Neovim 업그레이드 후였습니다.

    Chisnall 박사와 달리, 저는 Neovim에서 편집기 여정을 시작했기 때문에 전환으로 인해 물린 것이 아닙니다. 그러나 영구 undo 파일의 형식이 불안정하고 Neovim이 이전 형식을 인식하지 못할 때 그냥 삭제한다면, 형식을 변경한 후 업그레이드하면 파일도 삭제될 수 있다고 (제게는) 상상할 수 있습니다.

    아이고. 이것은 Neovim에서 벗어나는 것을 생각하게 만듭니다. 예, FOSS는 있는 그대로 제공되지만, 대안이 있다면...

  3. sdcfgy

    저는 vim이 Debian 저장소에 처음 등장했을 때부터 사용해 왔습니다. NeoVim이 더 낫고, 더 현대적이며, 많은 (편리하게도 결코 인용되지 않는) 문제를 해결한다는 말을 수천 번 들었습니다. 저는 그냥 무시하고 계속했습니다. 지금은 제가 정기적으로 사용하는 기능이고 NeoVim에서 문제가 될 것이라고 전혀 몰랐기 때문에 끔찍하게 정당화된 기분입니다.

  4. BarbaryCoast

    VIM의 개정 이력에 따르면, 영구 undo는 2010년에 출시된 버전 7.3에서 도입되었습니다. 따라서 Chisnall은 2000년부터 사용했을 수 있지만, 그가 쓴 책 중 적어도 두 권에서는 영구 undo가 없었습니다. 그리고 그것은 "거의 20년 동안 유지되었다"는 것이 아니라, 기껏해야 16년입니다.

    하지만 그것은 좋은 기능입니다.

    저는 버전 관리를 사용하여 그렇게 합니다. 편집기에 연결하여 "저장"이 "체크인"이 되도록 했습니다. 이제 제가 사용하는 도구에 관계없이 모든 상태에 대한 영구적이고 버전이 지정된 복사본을 가지고 있습니다.

  5. gchamonlive

    제가 뭔가를 놓치고 있나요? 사람들이 영구 undo를 백업으로 사용하나요?

    이것은 오히려 문서화 및 UX 문제처럼 보입니다. Neovim은 오래된 undo 파일을 삭제하기 전에 경고하고 물어봐야 하거나, 적어도 백업해야 합니다. 하지만 사람들이 신뢰할 수 있는 백업 및 버전 관리 시스템을 사용하지 않는 것은 neovim의 잘못이 아닙니다. 이를 위해 영구 undo에 의존하는 것은 일종의 자해입니다.

    작업에 적합한 도구를 사용하세요. neovim 개발자들이 "사용자에 대한 보호 의무 개념이 없었다"고 말하는 것은 정말 무례합니다. Neovim의 Lua API는 배려로 넘쳐납니다. 그냥 가서 보면 됩니다.

  6. ghtbircshotbe

    Neovim은 vim의 플러그인 대체품으로 광고되지만, 이는 100% 사실이 아닙니다. undo 파일과 :!를 포함하여 많은 것들이 다릅니다. 포기하게 만든 기능이 기억나지 않지만, 어느 시점에서 전환은 가치보다 더 많은 작업이 되었습니다. 제 vim 설정이 이미 작동하기 때문입니다. 오늘 시작한다면 무엇을 할지 모르겠습니다.

  7. natbennett

    저도 Neovim의 매우 초기 사용자였습니다.

    제가 개인적으로 기억하는 포지셔닝 방식은 "Vim이지만, 호환성을 깨는 변경 사항이 있는"이었습니다.

  8. justinmk

    Vim undofile "데이터 손실"은 Vim(VIM!)이 Vim이 실행되지 않는 동안 외부 도구(git, nano)가 파일을 변경하면 undofile을 재설정하기 때문에 발생합니다.

    한번 해보세요:

    # 몇 가지 편집을 한 다음 vim을 종료합니다(종료하는 것을 잊지 마세요).

    vim --clean +'set undofile' foo.txt

    # vim이 아닌 다른 도구로 같은 파일을 편집하고 변경 사항을 저장합니다.

    nano foo.txt

    # 파일을 다시 열고 "u"를 시도합니다. 그런 다음 Vim의 "보호 의무"에 대해 bluesky에 게시합니다.

    vim --clean +'set undofile' foo.txt

    이것은 `:help undo-persistence`에 문서화되어 있습니다.

  9. dlisboa

    > 파일 시스템에 있는 영구 파일이 사용자가 원할 수 있는 데이터를 포함하고 있다는 이유만으로 프로그램이 그것을 삭제하지 말아야 할 이유가 없다는 태도는 그들이 사용자에 대한 보호 의무 개념이 없었다는 것을 의미합니다.

    그것은 잘못된 관점입니다. NeoVIM은 사용자에 대한 다른 보호 개념을 가지고 있습니다. 그들은 현대적 기대에 더 부합하는 다른 종류의 보호를 위해 최적화하고 있으며, VIM은 그것에 신경 쓰지 않았습니다(따라서 포크).

    더 낫거나 나쁜 것이 아니라, 그저 다를 뿐입니다.

    같은 기사는 VIM이 네이티브 LSP 통합이나 자동 완성이 없고 사용자에 대한 의무나 보호가 없다는 것에 대해서도 쓸 수 있었을 것입니다.

  10. RVuRnvbM2e

    Undo 파일과 영구 undo는 그런 식으로 작동하도록 의도되지 않았습니다. 그것들은 단지 프로세스 재시작 간에 지속될 뿐입니다. 그게 전부입니다.

    그것들은 "사용자별 비필수(캐시) 데이터"로 정의된 ~/.cache에 있습니다.

    이 사용자의 인상적인 이력에도 불구하고, 그들은 단순히 이 기능을 오해했습니다.

이 날의 다른 글

2026-09-27