3 ms·

Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. Yo

Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. You get full IDE-like experience aware of all your local packages and external packages, typing resolution, Copilot, any editor customisations like vim keybindings etc. I don't think it just gets any better these days. Re: the fourth point, "version control", it requires a few hoop jumps if you really want nice diffs, like using "jupytext" either manually or via commit hooks. However, given that native .ipynb diffs are now rendered on GitHub, I'm not sure those tools will be worth the effort for an average user. // disclaimer: I did use emacs as the main editor for half a decade, am quite familiar with org-mode... and I still think nothing replaces magit as a git client, but that's another unrelated discussion

ParetoOptimal 4y ago
> Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. You get full IDE-like experience aware of all your local packages and external packages, typing resolution, Copilot, any editor customisations like vim keybindings etc. I don't think it just gets any better these days. > // disclaimer: I did use emacs as the main editor for half a decade, am quite familiar with org-mode... and I still think nothing replaces magit as a git client, but that's another unrelated discussion Aren't you agitated by the lacking the window management, inability to always use the keyboard, use of macros, and lack of `C-h k`?
- aldanor 4y ago
  Not sure if this is an /s comment or not, but: - full-blown super-configurable window management is barely needed for dev work aside from several editor panes, being able to quickly switch to terminal/vcs, being able to jump to any recent file or any open tab by fuzzy searching or shortcuts, etc - all of this exists in base vscode - I'm 99.9% cases I can use the keyboard, especially with vim keybindings. There's also command palette for almost every possible action - C-h k you can pretty much replicate (to an extent) by binding recordSearchKeys together with openGlobalKeybindings - Macros: global-level macros are not a thing in vscode unless you use third party plugins or hack something yourself. However, in vim mode you have all of the vim macro functionality which covers most of the typical use cases All in all, there's pros, there's cons. Emacs will always remain more configurable but suffers as an actual dev tool.
  - ParetoOptimal 4y ago
    > Not sure if this is an /s comment or not, but: Oh no... my opinion got confused as sarcasm :S No sarcasm here though! > full-blown super-configurable window management is barely needed for dev work aside from several editor panes, being able to quickly switch to terminal/vcs, being able to jump to any recent file or any open tab by fuzzy searching or shortcuts, etc - all of this exists in base vscode Last I paired with someone that used vscode there wasn't an equivalent for simply doing `C-x 3` from the keyboard and you had to use the mouse. Being forced to use the mouse in many situations was my main point here. > I'm 99.9% cases I can use the keyboard, especially with vim keybindings. There's also command palette for almost every possible action Ah, okay. I've never seen anyone use the vim keybindings in vscode and haven't used them myself in vscode. > C-h k you can pretty much replicate (to an extent) by binding recordSearchKeys together with openGlobalKeybindings Good to know. > Macros: global-level macros are not a thing in vscode unless you use third party plugins or hack something yourself. However, in vim mode you have all of the vim macro functionality which covers most of the typical use cases I'm assuming you are not counting "split git log of commits to the right, go to first one, add comment to top of file, go to next git log item, repeat" as a typical use case? Or the same for a macro operating on search results. > All in all, there's pros, there's cons. Emacs will always remain more configurable but suffers as an actual dev tool. Not in my experience. I've used vscode a bit and just have a fuzzy memory of what felt like endless small annoyances.

ParetoOptimal 4y ago

> Re: 3 of the points: "unified environment", "extensibility", "customisation": all of these are solved by just using notebooks inside VSCode using its client. You get full IDE-like experience aware of all your local packages and external packages, typing resolution, Copilot, any editor customisations like vim keybindings etc. I don't think it just gets any better these days. > // disclaimer: I did use emacs as the main editor for half a decade, am quite familiar with org-mode... and I still think nothing replaces magit as a git client, but that's another unrelated discussion Aren't you agitated by the lacking the window management, inability to always use the keyboard, use of macros, and lack of `C-h k`?

aldanor 4y ago
Not sure if this is an /s comment or not, but: - full-blown super-configurable window management is barely needed for dev work aside from several editor panes, being able to quickly switch to terminal/vcs, being able to jump to any recent file or any open tab by fuzzy searching or shortcuts, etc - all of this exists in base vscode - I'm 99.9% cases I can use the keyboard, especially with vim keybindings. There's also command palette for almost every possible action - C-h k you can pretty much replicate (to an extent) by binding recordSearchKeys together with openGlobalKeybindings - Macros: global-level macros are not a thing in vscode unless you use third party plugins or hack something yourself. However, in vim mode you have all of the vim macro functionality which covers most of the typical use cases All in all, there's pros, there's cons. Emacs will always remain more configurable but suffers as an actual dev tool.
- ParetoOptimal 4y ago
  > Not sure if this is an /s comment or not, but: Oh no... my opinion got confused as sarcasm :S No sarcasm here though! > full-blown super-configurable window management is barely needed for dev work aside from several editor panes, being able to quickly switch to terminal/vcs, being able to jump to any recent file or any open tab by fuzzy searching or shortcuts, etc - all of this exists in base vscode Last I paired with someone that used vscode there wasn't an equivalent for simply doing `C-x 3` from the keyboard and you had to use the mouse. Being forced to use the mouse in many situations was my main point here. > I'm 99.9% cases I can use the keyboard, especially with vim keybindings. There's also command palette for almost every possible action Ah, okay. I've never seen anyone use the vim keybindings in vscode and haven't used them myself in vscode. > C-h k you can pretty much replicate (to an extent) by binding recordSearchKeys together with openGlobalKeybindings Good to know. > Macros: global-level macros are not a thing in vscode unless you use third party plugins or hack something yourself. However, in vim mode you have all of the vim macro functionality which covers most of the typical use cases I'm assuming you are not counting "split git log of commits to the right, go to first one, add comment to top of file, go to next git log item, repeat" as a typical use case? Or the same for a macro operating on search results. > All in all, there's pros, there's cons. Emacs will always remain more configurable but suffers as an actual dev tool. Not in my experience. I've used vscode a bit and just have a fuzzy memory of what felt like endless small annoyances.