5 ms·

VS Code is certainly neat, but with the rush to cram everything into it, it's starting to feel more like emacs than vi.

by g051051 9y ago

zimablue 9y ago
But?
- g051051 9y ago
  Just making the point that it went from a simple text editor to a much more full-featured IDE wanna-be. That's a bit of a paradigm shift to me.
  - petre 9y ago
    That's why I've been using Atom instead. Since 1.17 or so it got quite usable and it's getting better with every iteration. Nowhere near as fast as Sublime Text but usable for daily coding. I disabled the git plugin because we're using fossil. I hope it doesn't become an IDE like VS Code. At least they made the IDE packages separate.
    - jorangreef 9y ago
      Regarding fossil, do you use fossil for tickets and self-hosting? How well do fossil tickets work compared to Github issues? Do you use any custom themes for fossil tickets?
      - petre 9y ago
        We used tickets somewhat and we are self hosting through a nginx proxy in order to log the http activity and proxy over https. The ticketing has markdown support. We use a custom theme, not for tickets but for the whole repo. Fossil tickets are only used internally, we use osticket regular ticketing. There is also a service for hosting fossil repos called Chisel, but it's nowhere near as useful as Github. http://chiselapp.com/ http://chiselapp.com/
        jorangreef 9y ago
        Thanks!
dbmikus 9y ago
I doubt any Electron-based editor is going to feel as snappy and light as Vi. Have you been noticing performance decreases? I haven't noticed any.
- ayushgp 9y ago
  VS Code is trying hard to be an IDE for all languages. If you use pure VS code without extensions, it quite snappy. But as you start adding more and more extensions, it starts slowing down and that too quite fast.
  - deleted 9y ago
    [deleted]
  - drunkkcunt 9y ago
    This is true, but its still very snappy for an electron app. After adding around 10+ plugins on Atom it not only became slower but it started crashing or having internal errors. With VS code I have 17 plugins installed and it still feels light enough. Personally I disable most plugins until I need them and I think most people should do the same considering how easy it is to disable a plugin. I have all my language specific plugins disabled until I need to use them.
  - AceyMan 9y ago
    Serious question— Does/would a high-end (e.g., Xeon-class) processor and/or a boatload of RAM help keep Code's performance snappy? FWIW, I run my Code install quite light since my "duties and responsibilities", ahem, only require a few languages/data types, ergo, I am not pushing it hard at all. FTR, I have a (licensed) install of Sublime, which I confess is snappier than Code, but the difference is so small I use whichever one is better for the task at hand and any difference dissappears under the pressure of an outage enforced deadline :-D
- Barrin92 9y ago
  > feel as snappy and light as Vi. this is only true if we're strictly talking editing text wihtout any plugin functionality. As soon as you add code completion features vim shows its age, the Ale extension for async linting for example feels very sluggish on a few only slightly dated laptops I tried out and frequently grills the cpu.
bad_user 9y ago
That VS Code is not Emacs-like, that’s my problem with it. In my experience nothing beats Emacs at editing text. Vim has better shortcuts, but Emacs is just smart about everything. My problem with Emacs is that it’s showing its age, it’s hard to configure and you have to learn an old and obscure LISP dialect for it. On the other hand I’ve heard that VS Code plugins are a joy to develop, MS apparently did a good job at that. But Emacs? Yes please, I want that — plus to be honest, in 20 years from now Emacs will still be around, whereas I have my doubts about these fancy new editors.
- signal11 9y ago
  > you have to learn an old and obscure LISP dialect for it As someone who is glancingly familiar with emacs (I have only ever written one elisp function, that too with help) it's a really stupid question, but couldn't emacs have bindings for lua or python or something? That would increase the number of people who can program for it and customize it. > in 20 years from now Emacs will still be around I think the real risk for emacs is, over the years, slowly losing the pool of people who care enough to contribute to it -- not just core developers, but also people who write packages, themes, etc. I already see a lot of developers who think Atom / VSCode / Sublime Text is "good enough". You may choose to discount Sublime because it's closed source (I do despite loving it otherwise), but VSCode and Atom are open-source and browser technology is only going to get better.
  - chaoky 9y ago
    Elisp would still a better much better language than python or Ruby (for emacs), especially now that lexical binding is becoming standard. Emacs people would like to move to scheme, if anything. (even RMS wishes emacs would move to scheme.)
  - dleslie 9y ago
    Emacs is a lisp; there's a very small and tiny layer of C at the bottom and everything else is a tower of lisp. You can interact with it with other languages, via many different means, but in the process you lose the joy and power of working in a live lisp environment.
jsight 9y ago
So you think it is awesome then?
- g051051 9y ago
  Nothing but love for emacs, props to those who use it.

VS Code is certainly neat, but with the rush to cram everything into it, it's starting to feel more like emacs than vi.

zimablue 9y ago

But?

g051051 9y ago
Just making the point that it went from a simple text editor to a much more full-featured IDE wanna-be. That's a bit of a paradigm shift to me.
- petre 9y ago
  That's why I've been using Atom instead. Since 1.17 or so it got quite usable and it's getting better with every iteration. Nowhere near as fast as Sublime Text but usable for daily coding. I disabled the git plugin because we're using fossil. I hope it doesn't become an IDE like VS Code. At least they made the IDE packages separate.
  - jorangreef 9y ago
    Regarding fossil, do you use fossil for tickets and self-hosting? How well do fossil tickets work compared to Github issues? Do you use any custom themes for fossil tickets?
    - petre 9y ago
      We used tickets somewhat and we are self hosting through a nginx proxy in order to log the http activity and proxy over https. The ticketing has markdown support. We use a custom theme, not for tickets but for the whole repo. Fossil tickets are only used internally, we use osticket regular ticketing. There is also a service for hosting fossil repos called Chisel, but it's nowhere near as useful as Github. http://chiselapp.com/ http://chiselapp.com/
      - jorangreef 9y ago
        Thanks!

dbmikus 9y ago

I doubt any Electron-based editor is going to feel as snappy and light as Vi. Have you been noticing performance decreases? I haven't noticed any.

ayushgp 9y ago
VS Code is trying hard to be an IDE for all languages. If you use pure VS code without extensions, it quite snappy. But as you start adding more and more extensions, it starts slowing down and that too quite fast.
- deleted 9y ago
  [deleted]
- drunkkcunt 9y ago
  This is true, but its still very snappy for an electron app. After adding around 10+ plugins on Atom it not only became slower but it started crashing or having internal errors. With VS code I have 17 plugins installed and it still feels light enough. Personally I disable most plugins until I need them and I think most people should do the same considering how easy it is to disable a plugin. I have all my language specific plugins disabled until I need to use them.
- AceyMan 9y ago
  Serious question— Does/would a high-end (e.g., Xeon-class) processor and/or a boatload of RAM help keep Code's performance snappy? FWIW, I run my Code install quite light since my "duties and responsibilities", ahem, only require a few languages/data types, ergo, I am not pushing it hard at all. FTR, I have a (licensed) install of Sublime, which I confess is snappier than Code, but the difference is so small I use whichever one is better for the task at hand and any difference dissappears under the pressure of an outage enforced deadline :-D
Barrin92 9y ago
> feel as snappy and light as Vi. this is only true if we're strictly talking editing text wihtout any plugin functionality. As soon as you add code completion features vim shows its age, the Ale extension for async linting for example feels very sluggish on a few only slightly dated laptops I tried out and frequently grills the cpu.

bad_user 9y ago

That VS Code is not Emacs-like, that’s my problem with it. In my experience nothing beats Emacs at editing text. Vim has better shortcuts, but Emacs is just smart about everything. My problem with Emacs is that it’s showing its age, it’s hard to configure and you have to learn an old and obscure LISP dialect for it. On the other hand I’ve heard that VS Code plugins are a joy to develop, MS apparently did a good job at that. But Emacs? Yes please, I want that — plus to be honest, in 20 years from now Emacs will still be around, whereas I have my doubts about these fancy new editors.

signal11 9y ago
> you have to learn an old and obscure LISP dialect for it As someone who is glancingly familiar with emacs (I have only ever written one elisp function, that too with help) it's a really stupid question, but couldn't emacs have bindings for lua or python or something? That would increase the number of people who can program for it and customize it. > in 20 years from now Emacs will still be around I think the real risk for emacs is, over the years, slowly losing the pool of people who care enough to contribute to it -- not just core developers, but also people who write packages, themes, etc. I already see a lot of developers who think Atom / VSCode / Sublime Text is "good enough". You may choose to discount Sublime because it's closed source (I do despite loving it otherwise), but VSCode and Atom are open-source and browser technology is only going to get better.
- chaoky 9y ago
  Elisp would still a better much better language than python or Ruby (for emacs), especially now that lexical binding is becoming standard. Emacs people would like to move to scheme, if anything. (even RMS wishes emacs would move to scheme.)
- dleslie 9y ago
  Emacs is a lisp; there's a very small and tiny layer of C at the bottom and everything else is a tower of lisp. You can interact with it with other languages, via many different means, but in the process you lose the joy and power of working in a live lisp environment.

jsight 9y ago

So you think it is awesome then?

g051051 9y ago
Nothing but love for emacs, props to those who use it.