4 ms·

As far as I understand, it's not a big deal as this is sort of the dumb end of the IDE- just the text editor part, not the compiler or debugger. Correct me if I

As far as I understand, it's not a big deal as this is sort of the dumb end of the IDE- just the text editor part, not the compiler or debugger. Correct me if I'm wrong. I don't know why anyone would bother using a microsoft text editor on linux, but if you are using windows you're already getting screwed pretty hard with telemetry If a windows-using colleague asks me what text editor to use, I just tell them to use notepad++ or geany. The hard part is moving them away from MSVSC++ to some command-line compiler or debugger (like msys/mingw) so they can make reliable/extensible build scripts.

noduerme 4y ago
One reason I chose VS is because I'm a small dev shop, often working alone, and it's one of the only good IDEs around with plugins for syncing via sftp. In many cases that saves me having to use a separate client or configure cloud rollouts for minor code changes. Small devs are the target audience for vscode and also the most likely to be negatively impacted if the environment fractures.
- cowtools 4y ago
  See, what I would do in my case is I would just make a bash script for sftp. I'm not even sure if small devs benefit from such a bloated editor: the time you have to invest in writing a script or learning a command-line tool is to some extent time invested in learning a fungible skill, whereas time you invest in learning a graphical tool is usually not as extensible or reliable. A major time-sink in a previous job site was just setting up the environment for new developers, renewing licenses, configuring plugins, dealing with unexpected errors due to the environment, etc.
  - noduerme 4y ago
    The upshot of such a graphical IDE for me is basically lots of panes and windows to rapidly search in. I might have one library I've branched 7 times for 12 projects and need to have a few open and jump quickly to which version some line of code is referencing. It also helps with keeping version control and history right next to the working files. A bash script would be fine for syncing but it's not going to give me a diff on each file before I upload to a production environment. Playing it that close requires tooling in some red and green to make sure you don't hit the wrong button.
    - pxc 4y ago
      Emacs buffer management and Git integration is excellent for the use cases you describe. Doom Emacs is a great starter kit if you know the absolute basics of vim cursor movement. Your workflow sounds particular, if you want to upload hodgepodges of multiple branches to various environments manually. But I think you could do the same kind of thing pretty well with lsyncd + git-worktree with a checkout for each environment, plus additional checkouts for whatever you're developing. Check out a different version of a file in the worktree associated with staging, and lsyncd automatically syncs that change to staging. (It sounds like VSCode serves you very well for now, so I'm not urging you to change or anything. Just thinking aloud about some alternatives and what using them might look like for use cases similar to yours.)

noduerme 4y ago

One reason I chose VS is because I'm a small dev shop, often working alone, and it's one of the only good IDEs around with plugins for syncing via sftp. In many cases that saves me having to use a separate client or configure cloud rollouts for minor code changes. Small devs are the target audience for vscode and also the most likely to be negatively impacted if the environment fractures.

cowtools 4y ago
See, what I would do in my case is I would just make a bash script for sftp. I'm not even sure if small devs benefit from such a bloated editor: the time you have to invest in writing a script or learning a command-line tool is to some extent time invested in learning a fungible skill, whereas time you invest in learning a graphical tool is usually not as extensible or reliable. A major time-sink in a previous job site was just setting up the environment for new developers, renewing licenses, configuring plugins, dealing with unexpected errors due to the environment, etc.
- noduerme 4y ago
  The upshot of such a graphical IDE for me is basically lots of panes and windows to rapidly search in. I might have one library I've branched 7 times for 12 projects and need to have a few open and jump quickly to which version some line of code is referencing. It also helps with keeping version control and history right next to the working files. A bash script would be fine for syncing but it's not going to give me a diff on each file before I upload to a production environment. Playing it that close requires tooling in some red and green to make sure you don't hit the wrong button.
  - pxc 4y ago
    Emacs buffer management and Git integration is excellent for the use cases you describe. Doom Emacs is a great starter kit if you know the absolute basics of vim cursor movement. Your workflow sounds particular, if you want to upload hodgepodges of multiple branches to various environments manually. But I think you could do the same kind of thing pretty well with lsyncd + git-worktree with a checkout for each environment, plus additional checkouts for whatever you're developing. Check out a different version of a file in the worktree associated with staging, and lsyncd automatically syncs that change to staging. (It sounds like VSCode serves you very well for now, so I'm not urging you to change or anything. Just thinking aloud about some alternatives and what using them might look like for use cases similar to yours.)