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.

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

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.

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.

* c/p in a gist

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

* save to PDF

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.

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

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

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)

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

* 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

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.

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

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

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.

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?

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.

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

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

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.

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.

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.

The shortcuts make it a non-starter for me.

Having to configure stuff even more so.

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.

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!

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

http://www.spacemacs.org

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

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

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

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.

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.

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.

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!

https://github.com/jisaacks/GitGutter

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

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

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.