I'm a pretty hardcore Emacs user, and I'll just come right out and say it: I hate Emacs. However, the only thing I hate more than Emacs is anything else.

I tried to move to Atom, because I've heard good things, I read you could extend it in JS and that sounded good to me. The difference between customizing Emacs and customizing Atom could not be more night and day in my experience. Emacs is like a living thing, as crazy as that sounds. I feel the urge to make a slight customization to a key (which happens often) I just ask Emacs what function the key is executing and either wrap it in a custom function, or advise the function. I usually write and eval these customizations in the scratch buffer.

Meanwhile, Atom makes me restart to get any changes detected. There wasn't any live documentation system that I could find (which is something I can't fathom not having now).

Emacs, in terms of customization, is simply light years ahead of absolutely everything else. It's absurd to me that we're still stuck with it because seemingly nobody who wants to make a text editor has learned the lessons it has.

I’m in a pretty similar situation with Vim. I don’t hate it, but compared to modern editors like Atom and Sublime I feel like I’m missing out on some features. Things like visual find and replace through a whole project, tight integration with Git, looking a lot prettier (even with a true colour terminal) make me a bit envious. And sometimes Vim just feels slow and laggy to me (I tried Neovim briefly but didn’t notice any difference).

Vim is very powerful so although it hasn’t got features like visual blocks, you can do pretty much the same thing with macros and shortcuts - as long as you know and remember them, but that’s the tricky part... Somethings it would be nice just to click a menu to find that feature you use one a month.

I tried switching to Atom but then got lost and felt it was no way near as powerful as Vim out the box (even with the Vim plugin), so here I am stuck with Vim :-)

> Vim is very powerful so although it hasn’t got features like visual blocks

Vim has visual blocks? Ctrl-v. Did you mean multiple cursors?

I would say try VSCode with the Vim plugin. VSCode is much snappier than atom, the Vim plugin is quite good, the configuration files are easy to edit, built-in awesome git integration and project-wide search, and amazing plugin support. I moved from a super custom Vim to VSCode and I'm pretty damn happy most of the time.

vim has visual find and replace across a whole project

https://github.com/eugen0329/vim-esearch

Over at howl.io we're building an editor that's live editable like emacs. You can eval snippets of lua or moonscript code and they take effect immediately.

Is the windows 10 version stable yet?

Lack of an intuitive and really good live help system is my main quirk with all editors, including Emacs. Of course, they all have some included help systems, but they tend to be slow to load (the worst!) or kind of cumbersome. I don't particularly like Emacs help system, for example. It shows you generic documents and it takes too much time to look things up.

If you're writing an editor and want to include a special feature, please consider an online help system that

-- allows you to view help about the mode and keyboard settings immediately by one keypress - with absolutely zero delay, at any time and ideally fullscreen - and return to exactly where you were before you looked up the documentation

-- optionally shows you continuous online help during your editing (like e.g. the contextually most important keybindings while you're editing)

I'm curious, then what makes you hate Emacs?

I'm not him, but I have the same opinion.

Emacs doesn't play super well with others. You can do a lot of things in emacs, but you can't do emacs in other things.

On the occasions that I'm writing Java, I find IntelliJ to be super awesome. But I get annoyed because the editor in IntelliJ is not emacs. I'd like to be able to do things I can do in emacs in IntelliJ. Realistically, that means replacing the IntelliJ editor with emacs, but at the moment that isn't really possible.

Some things you can use emacs for, like editing web forms (I used to do that with an extension in Firefox), but emacs is really not so great at being used in other programs.

As far as emacs itself, the somewhat crappy GUI rendering precludes creating an IntelliJ like experience.

I can't help but feel this is a shortcoming of some of the other apps you are naming. In particular, if they played well with $EDITOR then this wouldn't be an issue.

Instead, everyone almost always finds their own way of rendering the text editor portion of what they are doing. Consider, your concern could just as easily be shifted to complaining about IntelliJ. Why can't I easily call out to it to get the information it knows?

IntelliJ's GUI is 65535x better than Emacs's GUI. I'd rather have Emacs as the editor in IntelliJ than Emacs trying to deal with whatever information IntelliJ is providing.

Doesn't change my assertion, though. If we want to hold up Emacs as being more embedable and playing more nicely with other programs, that same bar can be set for the other programs.

And this is largely up to each person. I personally loathe the IDEA GUI. And most any GUI. I will grant that they do better screenshots, but I will take what is effectively a super powerful terminal buffer any day.

The bar could be set for other programs, sure. But the question was only about why we use emacs and hate emacs.

It doesn't change your point at all, but I simply have a different opinion and was asked about it. I don't really care about embedding intellij, I just want to use emacs in other things.

Ah, completely fair. I was intending to offer a complimentary point, not necessarily to change your mind on this.

I do feel it is a rather personal choice. As I said, I don't care for the IDEA GUI, but I understand others do.

That’s why language servers are in vogue.

And to be fair, if you view UNIX as the IDE, it fits with the idea of small programs working well together. GLOBAL actually gets pretty friggin close to perfect for code exploration in most languages. I haven't tried the latest completions modes. Mainly because I just haven't bothered setting it up. It is borderline terrifying to me to see how reliant on ridiculously powerful and integrated IDEs some folks have become.

The target audience is people who casually use the terminal (probably over ssh) and need something simple to edit a config file with. This comes with all the basics that people expect from a graphical editor like Notepad++ and comes with familiar keybindings from CUA applications. I could see something like this being very useful for that use case.

That's actually a big market. People coming from vim will wonder what would you use it for when vim is so much more powerful. But this is a godsend to users who are used to gui editors. If they want something that behaves like every other editor and IDE they use there is very little available. In particular I don't know of any terminal editor that comes as a single binary and uses standard keystrokes like micro.

The reason they don't use those standard keystrokes is because for a terminal there is a much older standard that takes precedence regarding control characters. What's ctrl-z do? Background, or undo? It's nice for undo, but losing backgrounding capability is crippling if you use it.

Solution. Add an additional unix control key to all keyboards.

Maybe actually instead of caps-lock.

I think I've solved all my keyboard related problems know.

The solution adopted by Unix-era GUIs, and the Macintosh, was to use a different key for GUI shortcuts rather than overloading Control. X11 generically calls it ‘Meta’, USB calls it ‘GUI’, Sun had Diamond, etc. It was only Windows that botched it, and the this-is-finally-the-year-of-Linux-on-the-desktop-trust-me-this-time crowd who slavishly imitate it while ignoring Unix experience.

Funny enough, I use the Win key on my keyboard effectively as a 'meta' for all my shortcuts in i3. It was the only key that wasn't doing anything.

It’s rare to need to background a console editor, and many can run commands themselves in the background. Combined with tabbed and split terminals not much if anything is lost.

> It’s rare to need to background a console editor,

LOL. My experience with an average of 5-6 backgrounded vims *per each named tmux session" which I use to keep track of different source files I'm working on goes against this. Sure, I can use vim's windows, but I don't want split screen usually (I'll use the other terminal I have open if I do). I don't use tmux's windows either really. It's more a way to preserve session when changing workstations (these are remote terminals), and preserve against network drops. I use each tmux session as a contained work environment for the most part. I do all my software development using vim on a remote server, and have for most of the last two decades. I've worked with numerous other developers that work similarly for professional projects, personal projects, or both.

Let's just say that there might be people that use the combined features of terminal applications, terminals, and remote connections in ways that you might think were rare, but actually have large following and leave it at that. :)

You may choose to do that but it isn’t required, I listed three alternatives that work fine and there are probably more. Going in and out of an app all the time is inefficient.

If I don't want a separate SSH connection for every tab, then some in-terminal level management is required. Additionally, it's not really that inefficient. It's no different than alt-tab in windows to background and foreground apps. In this case, it's like alt-tab when in a remote desktop connection.

But in the end it's not about whether it's efficient, it's about whether it's rare, and I think it's not from the different vim users I've encountered, which may be an entirely different subset than the ones you have.

It sounds like you’re already happy with vim, so why not keep it? Also the micro keybindings are configurable, so not much to see here.

I wasn't complaining about Micro. I wasn't complaining about vim. I was just noting why terminal applications don't generally use those same key bindings historically, and why it still matters today. The only reason we are off in the weeds like this is because of your assertion that it's rare to need to background a terminal editor, which doesn't match my experience at all.

I just open a new tmux window per-file I edit, named after the file. Well, I do still bg vim processes sometimes, but mostly I do the per-window vim thing. I even have a vim wrapper to do this so that editing files from cscope automatically starts a new tmux window with the vim in it and returns control to cscope.

It requires a modified setup, but you can set vim up to open multiple unsaved files in a single process. Not splits ir windows, but buffers. I have bindings set up to quickly do :bn and :bp and :bd. Your tmux usage sounds like mine, and if you did not know that there was depth to vim buffers this may be valuable to you.

I'm aware of stuff like that, and things like nerdtree. In the past, I've had many boxes I might end up on so I kept coming relatively stock to the distribution. In the last four to five years it's been primarily one box, so I've finally started putting in more advanced features slowly.

There are benefits to being comfortable in a somewhat stock Vin, and there are benefits to having it highly customized. I find the benefits imparted might be outweighed by the discomfort when it's not as you expect if your work flow forces that situation on you, so as my work flow has changed with the type of work I do, I've tried adopting different vim strategies.

I wrote an editor which more-or-less matches that description: http://www.github.com/marssaxman/ozette

I've never expected nor done any work to attract users other than myself, so there are a handful of rough edges I've never bothered to polish, but I have in fact been using this thing full-time for several years.

Perhaps I wouldn't have written it if micro had existed back then.

Cool, any screen shots? Would like to see the tabs with a few files open.

Thanks for your interest. I've added a couple of screenshots to the readme. I usually run ozette in a terminal filling one monitor, with 2-3 files open. It works fine with more, but you just can't see much of their contents; still, seeing the edges of the other files in a stack behind the active tab somehow helps my sense of spatial navigation.

It's funny how life works. There is nothing especially sophisticated about this bit of code, it has many little bugs I've never bothered to fix, and I'd design it completely differently if I started now. Still, though: after thirty-plus years writing code, I've gotten more actual use out of this little tool than anything else I've ever written. Judging by the ratio of hours spent writing it to hours spent using it, nothing else even comes close, not within an order of magnitude.

Windows doesn't have sshfs, do they? If it did, you could just mount the remote, and use whatever UI editor you want. I do this with gvim (but on Linux)

Coming from a Windows background, Vim/Emacs are alien to me and Nano feels underpowered and weird. For lightweight text editing, this appeals to me much more at first glance.

I would really like to see a fully featured terminal based editor that is built with modern keybindings in mind. I've given Emacs a solid chance but ended up switching to Atom (weird keybindings and configuration that kept breaking made me leave in the end). I like most things about Atom. The package system. How it's configured and navigated. But there's a simplicity (and memory footprint) of the terminal based UI that is missing to really make it the perfect editor (for me).

Agree. Though micro looks very good as a light weight editor for programmers, arguably better than vim in some way, it cannot move (neo)vim users like me away. Borrowing Linus Torvalds words on why he is using micro-emacs,

"My fingers cannot be retrained."

One use case would be a fallback editor for junior developers. It's still important to have syntax coloring for things like config files, JSON files, editing shell scripts and writing Git commit messages; and you can't always use the IDE for these things:

* The IDE can be too slow to start.

* Maybe it's not working today.

* Maybe it's not on the server.

Vim addresses nearly all the requirements -- it's reliable; it's easy to use as $EDITOR, to be called by other CLI tools; and it offers great syntax coloring and editing options. It's just that it's too confusing. The old joke about developers shutting off the computer to quit...

Please. Nowadays vim tells you how to quit. If you press control c, it clearly explains how to exit. I learned vim a few years ago, and immediately figured out how to exit it (just do what it says!) and by now it's my main editor and I love it.

> Nowadays vim tells you how to quit. If you press control c, it clearly explains how to exit.

I'm not sure whether I am happy or sad that it does that now.

I would imagine replacing the simpler editors, like nano.

Hardcore ex Nano user here. I prefer Nano nowadays since it has more sanity in key bindings and Works quite well as a replacement for Nano.

Do you use nano instead of nano? Is it typo?

Yeah a typo. I'm slightly sick and wasn't quite awake at the time.

I filled an issue regarding that but the maintainer seems absent.

When working over ssh, its handy to have a text editor for making small edits here and there. I'm very excited about this editor!

I use VSCode for 99% of my work but I have EDITOR=micro for quick edits and for all of my git message writing. I don’t want to load a vscode session just for a quick commit message, but I want longer free form than you can achieve with “-m”. I also bind save and quit to a single key combo for quickness.

Emacs _is_ a graphical editor. You have to type `emacs -nw` to make it run in the terminal under usual conditions.

I use Atom for most of my work, but sometimes it's more convenient to edit a file on the command line.