Hacker News Reader

Comment by lvoudour | Hacker News Reader

Sublime is probably the first GUI text editor that left me satisfied. Everything else over the years was either non-portable, slow or lacking features. After two months of use I just had to buy it, it's worth the price.

- It's fast and responsive, can handle large files and personally I've never seen it leaking memory or crashing

- Love the goto anything and command palette, brilliant

- Text editing is great and can be easily enhanced with existing plugins

- Theming is great

- Project handling is a bit weird, but once you get the hang of it it's fantastic

I don't do use IDE-like features (auto-complete, linting, compiling, etc.) nor integration features (version control for example) so I can't say how it fares in that aspect.

Recently I tried VSCode and Atom. They are portable and feature rich out of the box, but God are they slow and memory hungry. I can definitely see the appeal for web devs but it doesn't work for me, I value responsiveness above all else (that's the main reason I avoid dedicated IDEs)

View on HN

Have you ever seen UltraEdit? I dare you to try the trial, actually go through the exquisite configuration dialogs to make it yours, and then to ever look back :)

This isn't as a knock on ST, which I also like, and might even sometimes prefer for pure writing or temporary notes. But it doesn't even have printing out of the box, come on. For me that's too modern.. plugins are nice, but I guess I prefer UE to ST like I preferred old Opera to Firefox.

It's a very good editor; I always assumed it was windows only but it's multiplatform too.

I switched from UE to ST entirely because of UE's licensing/activation model.

Maybe it is different now, but UE used to require an internet connection for the registration... or you had to email your info for offline codes.

I have a bunch of isolated machines at work, physical and virtual, and got tired of dealing with UE and its registration requirements. Especially when ST gave a license key file I could copy around as needed.

So I switched. But yeah, I remember UE was a really good editor. Now I'm happy with ST.

It always amazes me how Ultraedit is completely invisible on Hacker News. It's been a very decent option for a very long time.

UltraEdit does column editing so much better than ST. I think I prefer ST overall but that one feature, when it's needed, is wonderful.

I use it in the office (on Windows) and yes, the column mode is the best I used. I did try the Mac version (of UE) but I think it was still in beta mode and I was not really impressed. But on Windows is really great.

>Have you ever seen UltraEdit?

A long time ago (>10 years) but then I mostly used IDEs for development. Didn't know it was still out there, I'll may give it another try, thanks

I have and switched when I discovered how badly UltraEdit choked on very large files.

Could you mention what you're likely to be printing? What sort of uses do you have where you write notes in a plain text editor and print them out? I can't think of the last time I printed anything -- actually, I should say I can't think of the last time that I printed anything that wasn't a contract or HR paperwork type of stuff, which is never in plain text. I'm curious what else is still being printed these days. Also, they have plugins for that, if you're interested. You're correct that it's not built in, though.

I print code reasonably regularly! Makes going through it with a highlighter and red pen to get a sense of what it does and what should be changed quite nice, and it's good to get away from a screen every now and then.

I mostly do it when I'm examining modules in a codebase I'm unfamiliar with.

That's interesting to hear. (Since this is the internet, let me be clear: that's not sarcasm)

Theoretically I really like the idea of reviewing code on paper.

But typically, if I'm trying to familiarize myself with a codebase, we're talking dozens of files. Usually I'm going through three, four, five levels of code to see how a request is served up, and then my search will fan out sideways into even more files as I attempt to see what other processes in the application might affect the data I'm concerned with.

For example with songs I'm in the process of making, I like to have a list on me with just the titles so I can note down acoustic observations made while listening to them on various speakers or headphones, for the next iteration of "mastering". Or little bits of info for my wallet, e.g. when a handwritten thing gets so old that I want to refresh it, then I'd rather make a printout and stick that in there. I like to make "cheat sheets" too, for work stuff or for all sorts of things, which aren't elaborate enough to warrant desktop publishing efforts, just proportional text. Granted, I don't print a lot, but for me it's still some of the very rudimentary things one might do with text.

> Could you mention what you're likely to be printing?

To paper? Never. To PDF? I've printed to pdf to get nice looking formatted code for presentations.

I see print as more a brute force bazooka feature to get nice vector graphics out of apps.

IIRC there's a Sublime plugin (obviously) that supports copy pasting formatted code with syntax highlighting. I definitely remember using it at university. Printing to PDF to get syntax highlighting just sounds like an unnecessary step in between.

What I do:

* c/p in a gist

* when looking at the gist, print the page in your browser

* save to PDF

You may want to a look at https://github.com/mplewis/src2png (it was popular on here at the beginning of the week https://news.ycombinator.com/item?id=15220069)

I fell in love with UltraEdit about ten years ago, and then I forgot completely about it. It amazes me how "obscure" it is when it's a fantastic replacement for ST, VSCode, Atom, Brackets, and dare I say, even Emacs/Vim.

First: I love ST. It is an amazing software that runs just as good on Mac/Linux/Win. In a pinch I will download and use it and never complain. Python extensibility is also great, since Python is the language I do best.

That said, and I hate to be this guy (not really), but... Emacs?

* Performance: Acceptable on modern day

* Goto Anything: Helm/Projectile, command palette = M-x

* Text Editing: It is what emacs does best as a program

* Themes: Yes

* Project Handling: Projectile

* IDE Features: These exist

* Source Control Integration: Many people use emacs purely because of Magit, it is a great git UI that people won't know about in general because it is runs on emacs

I copy my ~/.emacs.d to a server, literally my whole environment minus some tty nuisances just works. Everything. All my package versions. Emacs is stable enough that not many things break between big versions 23/24/25.

There are two areas ST wins: Out of the box configuration and performance on very big things. It is true the learning curve to settle all of these features I am mentioning is non-trivial, but Emacs is open source and, like I mentioned, very stable. It has gotten enough right in its initial concept that it will always be a fine environment to mangle up some text in files into whatever you want.

This brings me to my next point, there is nothing really new under the sun regarding text editing. Atom/VS Code/Eclipse/IntelliJ/Emacs -- you want to edit a bunch of files in a directory structure, navigate quickly and easily between files and get context important information about the code. Everything else is just flavors of those same chores, often specialized to a few programming languages or whatever new things are popular at the time (JavaScript / Can we build an editor in JavaScript).

I have seen very little innovation in the field of text editing. Light table was interesting, and its no surprise it is very Clojure/Lisp oriented. I am in a giant lisp machine when editing code in emacs, I can whack out a lisp expression anywhere and emacs will faithfully evaluate it for me.

Next point: If you work in a language or big project you need a way to navigate and generate lots of boiler plate in some languages (Java). IDEs help there, but...

Final point: The speed with which we write text as programmers is not the limiting factor of how much software we can produce and never has been.

My conclusion was to invest in one editor that has been around a long time and just not worry too much about it. I can use emacs in 20 years probably. Who knows about atom or vs code or whatever. So it isn't a pro emacs, you should use emacs reply to you, but that over the long run, using the same system to edit text is probably worth it. Stick with one thing and ignore everything else unless you are forced to use some IDE, and even then really try to avoid it. Even then I am pretty sure I could do my job with Gedit or Notepad without much of a productivity hit.

edit: formatting

I agree that finding an open source, well established and powerful editor is an investment worth making. That basically means vim or emacs. Once over the learning curve, you're setup for long term productivity gains and stability. Since neither editor is going anywhere and they run on pretty much anything.

But for many people, the initial learning curve just isn't worth it. Sublime, Atom and VS Code are all very popular because you just install them and start coding.

I'd love to see someone shake up the space with a "modern" take on emacs and vim: native, fast, powerful, very configurable, terminal based, but also with a conscious view on the initial learning curve and out of the box usefulness.

I think you should forget the whole "terminal based" thing. TUI text editors don't make much sense anymore. Native GUIs are much less clunky and much more discoverable.

I wish people would learn to appreciate that UX is subjective. I find most GUI-based editors to be RSI inducing. The level of effort required to change that is not worth it for me. Others may disagree. And that's fine.

Just because it's a GUI doesn't mean you have to use the mouse. I find gvim much faster than vim in the terminal because it doesn't have to print a screen full of glyphs for each update.

On the other hand, vim + tmux is pretty awesome, and for that reason I prefer vim on the terminal. I've never particularly liked gvim, even if I'm not using tmux. In Linux, hitting the start or end of a buffer causes some sort of screen redraw that I've never been able to fix, but that might have to do with my configuration.

TUI still has advantages. Editing files over SSH is simpler, the app is easier to build cross platform, and for me personally the lack of a context switch when I'm in my terminal is nice. Even tiny little differences that keep you in your flow add up.

I use Emacs in both modes.

I have my development machine at Digital Ocean. My local machine is an under powered macbook air (underpowered now that I use lots of docker for development). I'll probably just get a tiny chromebook next as I just want a dumb terminal.

I run emacs over ssh/tmux. I love it, emacs never shuts down, all my shells run through emacs as well. I can use any machine with my sshkey and be back to work immediately. I can increase the size of the machine, have public access to my dev box if needed. If I have a bad internet connection it doesnt matter since its just sending low bandwidth over ssh. All the real bandwidth comes from DigitalOcean and is super fast.

I do pretty much the same but using mosh instead of ssh. It's really stable even on low bandwidth of crappy mobile connection.

Well let's not generalize on the clunky part; there's always Visual Studio ;-)

I would generally agree with your point, especially on the discoverability front - this is why emacs and vim have an often dreaded learning curve. But OTOH, there are also a couple of rather nice benefits to the terminal focus that I don't currently see in more GUI focused editors. It would certainly be doable to replicate them, but it seems like no one's trying currently.

So I would hold off on forgetting about the terminal until there's a viable alternative around.

Oh, and: I've seen my fair share of botched remote access solutions on the Windows side of things and would probably use any TUI editor short of ed over any IDE in those situations. At least SSH is responsive.

Check out kakoune, TUI based and very discoverable.

> I'd love to see someone shake up the space with a "modern" take on emacs and vim: native, fast, powerful, very configurable, terminal based, but also with a conscious view on the initial learning curve and out of the box usefulness.

This sounds like the micro text editor. I've committed a few features to it and use it daily:

https://github.com/zyedidia/micro

You might be interested in checking it out.

> But for many people, the initial learning curve just isn't worth it. Sublime, Atom and VS Code are all very popular because you just install them and start coding.

This does a great disservice to the quality and functionality of Sublime.

I was a fluent vim user before switching to Sublime and have never looked back. The smooth (i.e. not line-by-line) scrolling and powerful multi-cursors were enough to draw me. The little things like a beautiful file explorer sidebar with icons-per-filetype, great package manager you can launch, search, and install from right in the editor, and yes, occasionally even the mini-map, all keep me here.

There's a pervasive meme on HN that Sublime took off because of its lesser learning curve, and that if you're a professional programmer you should make the investment to learn vim and emacs. But this ignores that a lot of people who have already made that investment still find Sublime to be a better editor.

While I can understand the importance of using an open source editor, that particular argument doesn't sway me since I'm happy enough using Sublime for now. If it stops getting updates or whatever, I can always switch back to vim, but for now I will use what I feel is the best editor for the job.

Sublime took off cause it just works and it has a nice default color scheme and just enough batteries included to make it a functional programming environment for the 80% of programming situations. And it now has enough addons to increase quality of life in many areas and or solve the other 20% in many cases.

If I install emacs it is just okay. It probably has syntax highlighting, depending on the Linux distribution. It probably doesn't have any quality of life improvements for language X. I can drop in a theme and colorize it pretty quickly to my liking. From there, emacs is still very powerful, but there are a lot of things I really love for long and deep editing sessions when I am going through a lot of files on a code review or what not.

Don't forget: it can be arbitrarily extended in a popular programming language and it has an unrestricted free trial.

ST or Emacs?

ST. Python is the popular language. Elisp is... not popular. But you can do CL in emacs.

As an aside I found the Leo editor not too long ago. http://leoeditor.com/ -- one of the few editors that made me think "that is a little new". Leo is implemented in Python.

I wish there was a modern equivalent of emacs, only all Python. :)

Yuck. I prefer what Neovim did: editor comminicates using RPCs with arbitrary external programs using over a socket. Zero language lock-in and maximum extensibility.

Addendum: then again, you could use Python to do that.

But for many people, the initial learning curve just isn't worth it.

I don't believe that. The people who snub Vim and Emacs, but are willing to sink time into learning new editors, new languages, and new frameworks have no excuse. If they were less susceptible to marketing, then they'd be able to learn something old every once in a while.

People have been attempting this for years with little success. The only projects I know of that have traction are Spacemacs and Neovim. The former is just an Emacs distribution and the latter is backwards compatible with Vim.

It is in fact possible to learn and KNOW Emacs and Vim and still prefer alternatives to either of them.

kakoune?

Kakoune doesn't run on Windows, so not cross-platform.

https://github.com/google/xi-editor

Current Status - from the readme:

This is still a project in its early stages. The Mac build has basic editing functionality (it was used to write this README), but looks very spare and is still missing essentials such as auto-indent. At the moment, it’s expected that its main community will be developers interested in hacking on a text editor.

Yeah, I'd love someone to make a text editor that is:

* simple and non-tedious to use by default,

* can run via terminal and ssh,

* supports vim themes,

* full support for Language Server Protocol,

---* (Can work with clangd)

* fast and polished

Maybe grandparent poster just likes Sublime better. If he was an emacs user, would you have posted basically the same thing with "...and I hate to be this guy (not really), but... Sublime?"

Gonna take advantage of having an emacs wizard around -

I love vscode, but agreed, it's bog-slow sometimes, especially when I run in ubuntu. I'm looking around at emacs and I like what I'm seeing, but something that perhaps seems silly is still a bit of a turn off for me - it's pretty effing ugly. I don't mean in the theme sense, I mean in all the stuff cluttering the codepanes.

In VScode I usually ctrl+k z for "zen mode," where the only thing you see is the tabs of your open files, and the code. ctrl+shift+e opens my file explorer when I need it, ctrl+b puts it away (or ctrl+p to go straight to a filename). Same for terminal, ctrl+`, do a git thing, ctrl+` buh bye. Anything similar for emacs? That level of quick control over the UI?

You can easily do that in emacs.

Throw this in your init.el

(scroll-bar-mode -1)

(tool-bar-mode -1)

(menu-bar-mode -1)

(global-linum-mode 0)

And it will instantly look a lot cleaner. If you want to toggle it you can turn it into a function and bind it to a key.

> (scroll-bar-mode -1)

...what? You're gonna take away the scrollbar just like that? Implying that the scrollbar is worthless? Scrollbar is very important to me at least, (especially a well-implemented one). It gives me a quick and instant visual understanding of how big the file is, where I am currently in the file, etc. The only improvement I have seen on the scrollbar is Sublime's minimap... I knew there exist emacs methods to get it working, but I could not get it to work (on Windows) in less than a few days so that's of no use to me.

The wonderful thing about the list provided by your parent is that it's optional. Pick and choose the pieces you want. Those may not be the same pieces your parent wants. Fortunately both of you can choose without inconveniencing the other.

Worth noting also, with the default settings, Emacs tells you what your position is in the buffer in the mode line (Top, Bot, All, or a percent), so the scroll bar is redundant as a visual indicator.

You can make your Emacs setup minimalistic by hiding the toolbar and scrollbar. This blog post gives a pretty good starting setup. https://emacs-doctor.com/emacs-strip-tease.html

C-x C-f opens files, but will also open a file explorer if the path is a directory. The 'q' key will immediately close the file explorer. I'm not sure about git interaction. I usually just use the Emacs shell to enter git commands.

Magit in emacs is highly recommended.

Just get emacs prelude and configure it to use helm everywhere. It is so close to my previous custom emacs setup that I just install prelude now on a new system and run with it.

I guess I never understood the custom emacs distributions for long time users. If you had a system that worked... lugging it around isn't hard. It is usually a few hundred lines of elisp plus packages, which you can freeze and zip up and they are probably going to work on an emacs release 5 or 6 years in the future.

I don't worry about it cause I just backup my .emacs.d and restore it anywhere I plan on editing very long. My whole .emacs.d with tons of modes and add ons is 73MB.

There /is/ something to be said with not making a mess of your initialization file and customizations. It is also very possible to keep glomming addons in and eventually get to a difficult place where various elements of extensions/modes/packages are fighting and that can be frustrating and I can see why many turn to well tuned emacs distributions.

There is two default UI elements in my emacs config:

Line numbers on the left and two lines at the bottom. One for the status bar and one for the "mini buffer" (where you put commands, search text, and receive short messages). Everything else is just the buffer (file) I am editing. You could turn the line numbers off with a simple configuration and key binding if you wanted, along with all the other UI elements.

This goes to the "Zen" of my emacs config. Its always just the buffer I am editing unless I need another dialog or UI element. The trick to making this work with no tree based folder explorers are Projectile and Helm. Projectile adds "project" concept to emacs and Helm adds fuzzy searching of everything almost everywhere that matters. Both can be taught to work around git repos. So you can say, whack some keys and see a list of files in your project. Then start fuzzy matching in the helm buffer that results by typing say three letters of a file. If its unique you press enter. File is open. If I really need a tree or explore a directory there is `dired` mode which lets you walk around the file system. There are even tree modes that I find pointless after using helm and projectile.

There is nothing built in by default. That is the biggest problem with emacs. You don't just sit down at it one day and get a polished environment that fits with what you like. It is something that is worked at. You eventually learn at least a little elisp and your customization powers keep growing. Eventually you either quit emacs or are good enough at lisp and configuring it that it becomes obvious, if not trivial, to do most things other editors can do.

Generally speaking it is almost certain you can customize it if you are asking a question like, "Can I do X.". Everything in emacs, even configuration dialogs are just text buffers. You just teach emacs how to interpret different text buffers in different ways to implement special functionality. Most of the heavy lifting of integration with most languages is already done if your language is remotely popular.

This was a long answer, but that goes to the heart of emacs. If you want a zen mode, emacs is there for you. You want a mode with weird little widgets and build output things everywhere, emacs has your back. :)

but...but...my poor pinky finger.

https://www.emacswiki.org/emacs/MovingTheCtrlKey

Yes. I actually have a hard time using control now if it isn't capslock, heh. On other computers IT IS NOT UNCOMMON FOR ME TO END UP TYPING IN CAPS. That said, caps to control is a great quality of life improvement for anyone that uses CTRL for anything, but especially emacs users :)

Recently, after some corporate IT crap required handing over my laptop for a weekend, it came back with a post-it note attached that said "your caps lock key is broken, let us know if you want a new computer."

> That said, caps to control is a great quality of life improvement for anyone that uses CTRL for anything

I agree. I've been a vim user for over a decade, but a few years ago I decided to try mapping capslock to ctrl and have never looked back. It's a much more natural place for a key that gets used as often as ctrl, while capslock is a key that is rarely used (as a matter of fact, my keymap doesn't even have a capslock at all anymore, and I haven't missed it!). Anyone who uses ctrl more often than capslock ought to give it a try, but beware:

> On other computers IT IS NOT UNCOMMON FOR ME TO END UP TYPING IN CAPS.

It's a real danger!

Ya, i did this a long time ago. All my computers have capsLock key mapped to CTRL

Same here. That's the original layout of UNIX keyboards, after all.

very cool, I didn't know that.

I'd recommend this even for non-emacs users who use terminals a lot. The tiny bit of extra comfort from ctrl-C in a shell alone is worth it. Add in tmux ctrl-B, or any readline shortcuts you use a lot, and you're onto a winner.

>That said, and I hate to be this guy (not really), but... Emacs?

The shortcuts make it a non-starter for me.

Having to configure stuff even more so.

Exactly. Many people want their editor to be very flexible and configurable and micro-optimizable to suit their particular needs, and that's awesome if it's what floats your boat. On the other hand, there are many of us who want to think about our editor as little as possible.

Sublime isn't perfect and it still requires tinkering from time to time, but its power vs. time investment equation is absolutely fantastic. It's a very get-shit-done style of editor. Emacs/vim are amazingly powerful but they are also big time sinks, both in terms of the initial learning curve and later customization.

You are right. I view emacs as a sort of religion or philosophy of computing. I don't use the metaphor lightly. It is pretty apt. It is my religion, so I would never put it on anyone else. I will share the cool stuff about it, but not in an annoying way.

The philosophy of using it is that eventually, in the long long term, the productivity gains should be reasonable or at least competitive with any other editor or environment. It should be a joy to use. Since I know I will probably only ever make a living crafting text I view it as an imperative to deeply master my primary tool. The other aspect is that it is free and old and stable. I can't ever achieve an RMS level of using open source things, but everywhere I can, I want the truly open thing, even if it isn't practical. I run Linux for this reason, even though it was a giant time sink making it behave and getting everything just so. But I can make things just so.

This fits in also with creating a distraction free environment. i3wm, emacs, I barely even see application menus these days, but I still use a GUI, I am not crazy. But it fits with my philosophy/religion of computing, so I am going to do it this way. If others agree, great. If they want to know about it, I will share. If they think it's crazy, from their perspective they may be right!

Learning curve can be a pain. Customization afterwards not necessarily, but I see where you're coming from. But once you are competent at Vim and you have it looking like you want it, it is nothing short of delightful. I feel motivated sometimes just because I get to work in Vim.

https://i.imgur.com/muNrKqX.png

spacemacs is solid if you want to try out a well configured emacs. magit, org mode, helm are amazing tools and part of the killer feature list of emacs. magit is so good even if I stopped using emacs tomorrow I would still use it for my git gui.

http://www.spacemacs.org

I try such distros every two years or so to see if it's gotten any better. Usually it's not worth my time from the start (fun thing is, I used to use Emacs for a year or so in uni, before turning to Vim and never looking back -- until I had to do Java, which meant Eclipse. I got back to Vim, but the last 5 years it's all ST with some sporadic attempts to like VSC).

Let's do this in realtime. I downloaded the latest Spacemacs.

1) Opening. Hmm, it's a zip not a DMG. Already losing me, but I'll stick, I'm not that shallow.

2) Hmm, it's just a bunch of source files? I guess the prominent "Download" link just gives you the configuration, not a bundled editor. I have to get Emacs from somewhere else. Grr... Lemme check their "Quickstart".

3) Yeah... the Quickstart link just gives you some BS that assumes you already know how to install this, and the "Install" button just gives a git command line to clone their repo. Back to square 1.

4) Fuck it, I'll use brew to install Emacs. Spacemacs doesn't even say which version of Emacs it works best with. I'll risk with what brew gives me.

5) Brew installation ends fine, with a caveat: "Please try the Cask for a better-supported Cocoa version". Now you tell me?

6) Anyway, I have an emacs, lemme git clone spacemacs now. OK, comes up, nice logo. Now, I have a huge emacs window -- so why is it asking me "first time" config questions in a tiny space at the bottom? And why doesn't it explain better what the various options (distro flavors) entail?

7) Let it do its install, then play around a bit. Close the window in evil mode (q!). I open emacs again, greeted with this:

  Found 1 new package(s) to install...
  --> refreshing package archive: gnu... [3/3]
  --> installing package: evil-unimpaired@spacemacs-evil... [1/1]
  An error occurred while installing evil-unimpaired (error: (wrong-type-
  argument package-desc nil))

Oh, and:

  Warnings:
    - Cannot find any of the specified fonts (Source Code Pro)! Font settings 
    may not be correct.

8) I open some local source files to check. A buffer window appears on the right side with "warnings":

  Error (use-package): helm :config: Symbol’s value as 
  variable is void: helm-bookmark-map

Yeah, fuck that. Back to ST3.

That's actually a pretty good barrier to entry. With emacs/spacemacs, if installing it is too frustrating for you, then configuring and using it is going to be way too frustrating for you.

Yes. And god forbid it plays out of the box end to end with configuration/elisp being totally optional.

For the most part it is completely optional to configure it and use elisp... it will ask you if you want to install a layer (group of packages) when you open up a filetype that it knows about and can handle. there is some configuration akin to setting up completion backend, linters, formatters etc that are applicable to your language/filetype of choice. The benefit of that is that the external tools are kept external where development of them can continue unimpeded by the development of the main text editor.

similarly, once you get to know the language quirks, it's a decent language that is basically a DSL for text editing. The power you get from being able to lookup how something was implemented by the text editor developers easily is extremely powerful.

If you like vim's idea of modal editing, emacs is 100% all about that. languages are major modes, minor modes are functions and keybindings that can be enabled and grouped together at will. transient buffers are used to send output to and are treated as normal buffers that you can do things to. The architecture and extensiblity of emacs is pretty amazing actually. Every key press is just a function and every key can be rebound based on current context using things like mode maps that get layered on top of everything and have precedence based on where you inserted the binding with sensible fallbacks when required.

Disclaimer: I love vim as a concept but hate viml and the plugins that were hampered by the lame programming language that was designed by bram.

if you have not tried magit and org mode you just don't really understand the power of emacs and the power of having everything be a function. spacemacs just makes setting up that powerful environment fairly painless but it's still a very old architecture with some warts.

My opinion is that emacs/spacemacs is more optimized for day to day work, than for the out of box experience. Personally, I'm fine with that, and there are some great editors (like sublime) that work out of the box if you prefer that.

However, the people generally working with/on emacs are not looking for that, they are looking for an editor optimized for customisation. They have already gone through the experience of setting it up, so why would they spend most of their time making it easier out of the box?

There is a cost to everything, and so far most people on emacs side have decided to spend their time on improving it's power, not it's ease of use.

To play devil's advocate here.

you clicked on download instead of install. now, to be fair, download shouldn't be on the main screen imo but still install is more in line with what you were looking to do so it should have been the thing you clicked on. Cloning the repo is installing it if you have emacs installed already.

It's open source so this can verbiage can be fixed. It's not a stand alone editor as it's a bunch of configurations to emacs.

https://github.com/syl20bnr/spacemacs has better onboarding docs than the homepage does.

At the end of the day it's a question of how much customization you want out of an editor. Reading the tone in your comment seems like you didn't want it to be successful at all anyway.

Whereas Sublime "just works", emacs doesn't.

But when you're on Windows, boy you have to do a LOT to get it to just work. I tried it (and spacemacs, as I'm quite familiar with vim) last month for doing some python work on Windows... I just gave up after 2 days.

A couple of things that normally annoy me are that it's just a .zip file not an installer so the user has to figure out a "sensible" place to install it is ... and that there's like emacs.exe, emacsclient.exe, runemacs.exe or whatever - a bunch of .exes and it's not clear unless you've dug around a bit[0] which is "correct".

But after that it was relatively plain-sailing for me. What else was troubling you? Note: it's possible that we've got totally different workloads and needs - not saying you're doing anything wrong, I'm just curious

[0] - OK you don't have to dig far, (it's on https://www.gnu.org/software/emacs/download.html) but it still annoys me a tiny bit

> there is nothing really new under the sun regarding text editing

This may be true in for single heroic innovations, but sometimes the 'new' can emerge from successive refinement. I find this to be the case for IntelliJ. Working in it in static languages (at least the ones it knows well) just feels to me quite different from merely 'editing text'. The depth of code intelligence, combined with hundreds of small refinements in the way commands like refactoring work, affords a sense of working with syntax and structure, not 'text'.

> The speed with which we write text as programmers is not the limiting factor of how much software we can produce and never has been.

Again what IntelliJ adds for me isn't 'speed', but a cognitive sense of moving up the abstraction hierarchy. I'm thinking in terms of things like 'add a parameter to all call sites' much more than I am editing 'text'.

(caveat: I did use vim quite extensively many years ago, but never got beyond the learning shortcuts phase with emacs. It's possible either of the big 2 have similar refactoring and code intelligence packages available now)

Not everyone has this luxury, but I simply avoid languages that require an IDE to be productive or think abstractly. Alas, not everyone can get away with this. Also, IntelliJ is also a very nice editor. I have used it a decent amount and liked it well enough when editing Java.

I've used IntelliJ IDEA since forewer and I can only agree, and add a little bit of my own.

Having worked extensively with primareliu Java in IDEA, I have come to consider syntax something that is more a presentation layer issue than something actually important to the core differences between languages.

I suspect that this shift in what I consider important parts of a language is at least partially down to an IDE that for the most part lets me think about the concepts I am expressing, rather than their superficial expression as text on a computer screen.

> Working in it in static languages (at least the ones it knows well) just feels to me quite different from merely 'editing text'. The depth of code intelligence, combined with hundreds of small refinements in the way commands like refactoring work, affords a sense of working with syntax and structure, not 'text'.

These days, out-of-process, editor-agnostic code analysis engines or "language servers" provide many IDE-like features to any text editor that is scriptable and can do basic IPC. Examples include:

* Tern for Javascript

* rtags for C and C++ (I use this all day, every day, at work, it's remarkable how good it is)

* Go's oracle tool

* racer for Rust

* tools.nrepl for Clojure

All of these have solid editor support; at the very least, a good package is available for Vim, Emacs, and Sublime Text.

IDEs tend to be all or nothing. I'll open one on occasion for a particularly nasty debugging session. I wish, though, that half the development effort going into IDEs were instead directed towards better editor-agnostic tooling.

The only one of those I have tried is tern, which didn't come close to IntelliJ's analysis, but obviously Javascript's a harder beast in this respect than Java, kotlin, Objective-C etc.

> I wish, though, that half the development effort going into IDEs were instead directed towards better editor-agnostic tooling.

In principle I agree. I like the thought of composable tools. But I wonder in practise. I'm trying to picture the vast array of facilities integrated in IntelliJ (analyses, many refactorings, syntax-aware snippets, amazing code navigation, structural search & replace, data flow anaylysis, syntax-aware select, omnipresent code generation, etc) integrated into a text editor via external tools. I suppose it could be done, but it seems unwieldy. And with how much work (setup and maintenance) on the part of the user? How often would things clash or need fixing? And with how much discoverability (a critical feature of IntelliJ)?

What I do know is that working with code (not mere text!) in IntelliJ is quite a joy for me. For now, I'm glad someone has built it, even if the 'ultimate' composable set of tools might have some advantages.

>That said, and I hate to be this guy (not really), but... Emacs?

I intentionally didn't include console editors, totally different beasts. Never used emacs, only learned vim and only touched the surface, mostly use it when I ssh to remote machines. The pinnacle of flexibility and responsiveness but the learning curve... it's just too much for me.

You're right though, it's a great investment and as the years pass and mouse usage takes its toll on my right hand fingers, keyboard only editors look even more appealing. Whenever though I sit down and try to code in vim I find my productivity plummeting. I know once I ride the curve things will improve but unfortunately I find it hard to persevere

> keyboard only editors look even more appealing

You don't say what editor or IDE you're currently using [ed: unless you mean ST? Which would be odd, because it doesn't need a mouse for anything], but few require mouse usage for much nowadays. You might be better off, at least in the first instance, just learning the keyboard shortcuts for the tool you're currently using.

ST is not a modal text editor. I know there is a vim emulation plugin for ST that's reasonably good, but at face value someone who has mastered vim can edit text faster than vanilla ST because of vim's modal and compositional nature.

I use emacs in an X window 90% of the time, but it almost universally translates over to a tty. Fonts are just easier when it runs as an X window :)

> I copy my ~/.emacs.d to a server

I think if you work on servers a lot, then it's a major advantage to use something like emacs or vim, because your editing environment is 'just there'. But heaps of developers rarely, if ever, find themselves in a terminal, so the portability advantage just isn't there for them.

Emacs gives me RSIs due to the awkward chording. I love the idea of Emacs, but the reality is too painful. I love Vim though.

I prefer VSCode if the hardware can handle it, but otherwise Sublime is my goto. If Sublime ever had as good Git support as VSCode I would permanently switch back to Sublime

I've been very satisfied with https://github.com/divmain/GitSavvy and GitGutter. Together they are how I do almost all of my git.

another vote for gitgutter. jumping to the next changed hunk in my currently open file is a life-changer.

https://github.com/jisaacks/GitGutter

I think Will Bond has a git plugin that's supposed to be pretty good. I don't like VCS plugins in my editor though, so I've never tried it.

Text editors shouldn't come with hardware requirements.

All software has hardware requirements.

Even ed has hardware requirements.

Honestly out of the box Git management for VSCode is really good. I'm surprised how quickly it got integrated to my regular workflow, and I'm a terminal gitter to boot.

The ability to see side by side diffs and which files/lines I've touched is what did it for me. I still use git CLI for squashing, rebasing etc, but basic staging and committing I do entirely in VSCode now.

If you want git support out of the box, please give me a thumbs up on this PR. https://github.com/sublimehq/Packages/pull/1126 If you can read sublime-syntax files, code review is appreciated as well.

With this package, you can set Sublime to be your git editor like this:

  $ cat ~/.gitconfig
  [core]
    editor = subl -w
  ...

GitGutter and GitSavvy have been fantastic for my Git mileage -- have you tried them?

I prefer VSCode mostly for the intellisense/auto-complete.

As far as git is concerned, I use it from the command line an cannot understand why anyone would want to interact with git from VSCode or any other text editor.

I don't know if these editors support it, but being able to access git blame from editor is convenient, also the editor can highlight all the changes you've done since the last revision (especially useful to hunt down unnecessary whitespace changes).

Have you ever tried TextMate? Since like me, you don't like "IDE-like features" I can imagine TextMate 2 could be a better fit than Sublime, especially in respect to file management. And a lot of Sublime bundles are compatible with TextMate (and the other way around of course, since these bundles originate from TM)

Reply on news.ycombinator.com