Thread

1. dlisboa · 1790522895 · focus · HN ↗

   > the attitude that just because something is a persistent file on your filesystem that contains data that you might want is no reason for their program not to delete it meant they had no concept of a duty of care to their users.

   That's the wrong way to look at it. NeoVIM has a different concept of care for their users. They're optimizing for another kind of care, more in line with modern expectations, which VIM did not care about (hence the fork).

   It's not better or worse, just different.

   This same article could've been written about how VIM has no native LSP integration or autocomplete and they don't have duty or care for their users.

   1. jeremyjh · 1790525324 · focus · HN ↗

      It is insane that people are defending behavior that is clearly abhorrent just because they like the software. Are the claims even true? If they are, you should be updating your opinions about the person writing this software.

      1. dlisboa · 1790526058 · focus · HN ↗

         Insane? Abhorrent?

         Relax for a second. Get some perspective.

         1. jeremyjh · 1790526882 · focus · HN ↗

            My perspective is that the Neovim maintainer implemented a change that would delete data created by another program on other people's computers. They knew this would happen in advance, and it was done anyway.

            1. em-bee · 1790545174 · focus · HN ↗

               vim and neovim have different defaults for the undo file, if neovim overwrites a vim file then it can only be because the user changed the paths for both to be the same. in that case neovim had no way of knowing that the file was used by another program.

               1. kelnos · 1790549038 · focus · HN ↗

                  AFAICT neither has any default for `undodir`; the user must set it explicitly. I think a user could be forgiven for assuming that it was fine to use the same value when trying out a migration from vim to neovim, and that neovim wouldn't actively delete vim's state data.

                  Sure, maybe they should have backed it up or used a different directory, but I think it's reasonable to expect that many people wouldn't. If a software developer is only going to consider the scenario where their users are thinking/behaving exactly as they are, then they aren't particularly good at what they're doing.

                  1. em-bee · 1790559714 · focus · HN ↗

                     vim: Undo files are normally saved in the same directory as the file

                     neovim: by default they are saved to the dedicated directory in the application data folder

                     I think a user could be forgiven for assuming that it was fine to use the same value when trying out a migration from vim to neovim

                     neovim would also overwrite its own old version of the file. the point is that the expectation that neovim should watch out for files that are used by other applications is in my opinion not reasonable. it won't even watch out for its own old undo files.

                     users may have the expectation that neovim and vim are compatible, but that expectation is simply not entirely fulfilled. you can't share config files unless you have some minimal ones that just happen to work. so why would you be able to share other files?

                     the question is, how are these expectations formed, and what is reasonable to expect?

                     when it started out neovim was very compatible with vim. but from my experience with FOSS and based on the stated goal of neovim at least to me it was clear that compatibility was not going to last. not everyone shares that experience, and thus their expectations are different. neovim should perhaps make that more clear and for one be aware that people expect compatibility and warn users accordingly. an argument could be made that if a user changes the undodir value, there is a higher chance that they may try to use the same for vim. but then vim devs would need to do that too.

                     but does not considering that make devs not good at what they are doing? i don't think so. for one, if someone thinks the devs are not good enough they should stop using neovim (as some people here in the thread announced they are doing. their choice). personally i think this is average for FOSS and good enough. we can't expect everyone to be perfect. the correct response to an issue besides reporting it is not to complain but to contribute a fix.

            2. zeratax · 1790846914 · focus · HN ↗

               that's not what is happening here though?

               <a href="https:&#x2F;&#x2F;github.com&#x2F;neovim&#x2F;neovim&#x2F;pull&#x2F;13973#issuecomment-879067052" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;neovim&#x2F;neovim&#x2F;pull&#x2F;13973#issuecomment-879...

               &gt;&gt; It shouldn&#x27;t overwrite an unreadable file tho, unless I have completely misread the code.

               &gt; It doesn&#x27;t, but because it reads the vim-specific config file from the vim-specified location it then writes a file in that location with the name that vim expects, so files that I first edited in neovim ended up with undo files that vim couldn&#x27;t read and vice versa. Both programs complained.

      2. [deleted] · 1790526581 · focus · HN ↗

         [deleted]

      3. kebman · 1790527338 · focus · HN ↗

         From Cambridge Dictionary:

         ```markdown

         abhorrent

         &#x2F;əbˈhɒr(ə)nt&#x2F;

         Abhorrent is an adjective that means morally very bad, hateful, or causing strong disgust and loathing.

         ```

         I realise that this causes strong disgust and loathing in you, but can you please expand upon how it&#x27;s morally very bad to prioritise speed and ease of use over undelete capability in Neovim? Are you unable to make backups or use Git?

         1. overfeed · 1790528761 · focus · HN ↗

            You are presenting a false dilemma: Neovim could have easily done both without the deletion. Willful negligence is morally very bad when it can cause user harm.

            &gt; Are you unable to make backups or use Git?

            Ah yes, the old perty theft justification as applied to intentionally-inflicted data loss; &quot;They won&#x27;t mind if I take&#x2F;delete this, they (should) have insurance&quot;.

      4. oh_my_goodness · 1790528442 · focus · HN ↗

         Sci-fi premise. Somewhere [1] there is a message board where developers openly celebrate those feelings of dislike and disdain toward users.

         On that board, silently deleting a user&#x27;s files is obviously justified. What would be out of line is complaining about software silently deleting user files.

         [1] Long ago. Galaxy far away.

Unofficial Hacker News client; not affiliated with Y Combinator.