4 ms·

I fought for Atom for a long time. But after browsing a node_modules folder in Code, I realized how much I'd just accepted poor performance. It also worked as g

by Pigo 9y ago

I fought for Atom for a long time. But after browsing a node_modules folder in Code, I realized how much I'd just accepted poor performance. It also worked as good on my Linux devices as my work pc.

whipoodle 9y ago
My impressions were the same. Unfortunately VS Code caused some data loss on the first day I tried it, so I chose to keep using Sublime, but it seems really good overall.
- nerdponx 9y ago
  data loss Care to elaborate? Might be good to help others avoid the same problem.
  - whipoodle 9y ago
    Basically, it closed a buffer because the backing file disappeared when I checked out a different branch. So I guess the lesson is use your file system to retain data and never your editor, which sounds obvious and you could certainly argue the loss was my fault. But I do that all the time with Sublime and never had this problem once. In fact I could quit Sublime altogether and the data would still be there when Sublime reopened. Basically, I can see how the choice they made is a reasonable one, but my stance is a buffer should never close until I say so. If the backing file disappears, the last contents of the buffer should stay in there until I close it. I bet a lot of people will never get bit by this, but it's nasty enough that I think they should reconsider this decision. But for me it doesn't matter, I don't want to lose work because I trusted my editor to hold on to something and it didn't, so I'll likely never use it again.
    - betenoire 9y ago
      I think every editor can probably configured to do this. I've set up my VIM to do this specifically (auto reload the buffer when the file is modified). I don't think that one's on VSCode.
      - _tulpa 9y ago
        They're not configured to do that by default, most of them ask prompt you if a file changes. This one is on VSCode for having unsafe default behaviour which is also different to pretty much all the other editors.
        bpasero 9y ago
        VS Code will never close a buffer that has changes (e.g. is dirty). In this case, the buffer was closed because the editor was not dirty. You can change this by configuring "workbench.editor.closeOnFileDelete": false
        nerdponx 9y ago
        Having that default to "true" is really silly. VSCode is OSS right? That seems like a mulligan pull request to me. I can't imagine anyone is relying on the default behavior as-is.

by Pigo 9y ago

I fought for Atom for a long time. But after browsing a node_modules folder in Code, I realized how much I'd just accepted poor performance. It also worked as good on my Linux devices as my work pc.

whipoodle 9y ago

My impressions were the same. Unfortunately VS Code caused some data loss on the first day I tried it, so I chose to keep using Sublime, but it seems really good overall.

nerdponx 9y ago
data loss Care to elaborate? Might be good to help others avoid the same problem.
- whipoodle 9y ago
  Basically, it closed a buffer because the backing file disappeared when I checked out a different branch. So I guess the lesson is use your file system to retain data and never your editor, which sounds obvious and you could certainly argue the loss was my fault. But I do that all the time with Sublime and never had this problem once. In fact I could quit Sublime altogether and the data would still be there when Sublime reopened. Basically, I can see how the choice they made is a reasonable one, but my stance is a buffer should never close until I say so. If the backing file disappears, the last contents of the buffer should stay in there until I close it. I bet a lot of people will never get bit by this, but it's nasty enough that I think they should reconsider this decision. But for me it doesn't matter, I don't want to lose work because I trusted my editor to hold on to something and it didn't, so I'll likely never use it again.
  - betenoire 9y ago
    I think every editor can probably configured to do this. I've set up my VIM to do this specifically (auto reload the buffer when the file is modified). I don't think that one's on VSCode.
    - _tulpa 9y ago
      They're not configured to do that by default, most of them ask prompt you if a file changes. This one is on VSCode for having unsafe default behaviour which is also different to pretty much all the other editors.
      - bpasero 9y ago
        VS Code will never close a buffer that has changes (e.g. is dirty). In this case, the buffer was closed because the editor was not dirty. You can change this by configuring "workbench.editor.closeOnFileDelete": false
        nerdponx 9y ago
        Having that default to "true" is really silly. VSCode is OSS right? That seems like a mulligan pull request to me. I can't imagine anyone is relying on the default behavior as-is.