Hacker News Reader

Comment by g051051 | Hacker News Reader

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

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.

> 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.

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.)

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.

> there's a very small and tiny layer of C at the bottom [...]

That layer of C is hardly "tiny." Everything from font drivers to process management to a lisp interpreter to window and buffer code, to overlays, and a lot more.

There's 1,262,537 lines of elisp in 25.3, compared to 291,203 lines of C and C headers. While there is a fair amount of C code to do what you mentioned, much of the C is definitions for the core lisp language with 1,483 DEFUN statements in it.

But yah, not tiny, sure. I'm looking forward to it being replaced via the REmacs project.

https://github.com/Wilfred/remacs

> but couldn't emacs have bindings for lua or python or something?

It can, and here is an example: https://blag.bcc32.com/ecaml-getting-started/2017/11/05/emac...

And here is a better link I guess: http://diobla.info/blog-archive/modules-tut.html

But there is an Emacs clone with JS bindings, and it's called Atom.

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.

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.

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.

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

> 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.

This. Vim also has a nasty habit of hanging completely if something goes wrong at the filesystem level (e.g. a disconnected sshfs mount).

I also noticed ALE was very slow with JavaScript so changed it to run on save only.

However Neovim’s plug-in architecture is a big improvement. I’m running Deoplete (which provides intellisense like functionality) on the same machine, and it is basically instant. There are GIFs at the bottom of the repo:

https://github.com/Shougo/deoplete.nvim

Hey, thanks for that tip. This is really great. I'd never used neovim and almost switched to vs code but this is working really well!

So you think it is awesome then?

Nothing but love for emacs, props to those who use it.

But?

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.

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.

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?

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/

Thanks!

Reply on news.ycombinator.com