Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My two cents; there's a ton of space for productivity improvement in editors. Projects that allow more and newer features is what I'm interested in.

I don't like the fact that Atom and VSCode are slow and memory hogs. I do like that fact they are running in a cross platform environment with access to canvas, webgl, svg, images, video, networking and more. I want to see where that integration leads. Whether it's inline diagrams or code flow diagrams in a separate pane or ???

I also like the idea that editors could be written to be more friendly to plugins and customization than previous editors. I get that emacs and vim can be customized but there is arguably room for improvement. Whether it's easier APIs, an in editor plugin browser/installer, or things like Microsoft's external code meta data protocol that potentially let's more editors share support for more languages.

Of course I want speed and I have not switched to either Atom or VScode yet but both seem like a step forward where as emacs, vim, and even sublime feel stuck in a previous generation of design



> I get that emacs and vim can be customized but there is arguably room for improvement.

There is, of course, always room for improvement, but I think you are selling Emacs short here. Emacs is roughly 85% lisp, which is what you write to extend it. Not only do you have access to everything the core parts of the editor have access to, you can jump to the source of any editor function to see how it works. Since most of it is written in Lisp, you can assume that it has been dogfooded to death. Lisp is very much a first class citizen. And practically every public function is documented, and that documentation is just a keystroke away (C-h f).

When you launch Emacs with no filename it even dumps you into the "scratch" buffer, which is really just a lisp repl. Everything about Emacs is geared toward not just customization, but full on extensibility.

Emacs also now has all the stuff you'd expect—browsing, downloading, upgrading extensions (called "packages"). It also supports customizing the editor without writing any lisp code (M-x customize-*) if you don't want to be forced to learn lisp right away.


Emacs still has quite a lot of energy, people are working on deep levels (core, guilemacs) and the community is handling the userspace part through packages (melpa, etc). There are a few warts in a way compared to the layouting flexibilty of html/css, but beside that, the ability of emacs[-lisp] to absorb any new idea is still very high. Long time ago, when Sublime grabbed a share of the market, there was a 2 hour long video about what ST brought you. I yawned all along. The few things that weren't already in emacs appeared organically in no time; whereas 70% of features were there since the 90s.

My view is biased, I'm in a lexicalist period (blame it on sml) where I want a few equations, type constraints etc and no visual flexibility (which I wanted in the past).


His point wasn't that Emacs has fewer features, his point was that many of those features are half-baked compared to the implementation provided by Sublime.

You give up a bit of flexibility for more stability and overall polish.

That seems like a fair point.


That's almost true; surely the flexibility makes the system a little less "solid" in appearance. Just like a bare unix shell looks like frail compared to a full fledged GUI application. But for those who likes depth, it's not fragile or half baked, it's decoupled.


Ummm... if something doesn't work as advertised, it's frail. Don't try to use weasel your way out of this by invoking "depth" :)


I meant more as in 'feature A isn't doing everything I wished it was'; not as not doing its main task.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: