I "use" vim (neovim to be specific) as my primary editor. I quote use, because the only commands I really remember are the basics like y, d, u. I plan on learning it fully (or at least learning more commands) at some point, but those are good enough for me currently.

I forced myself to use emacs for all my text editing at some point and never looked back.

If you stare into the parentheses, the freedom stares back at you

or something.

The main reason is that you bend it to your will for example:
the other day I wanted to be able to insert n blank lines either above or below the current line - without moving the cursor. A few minutes later I have 2 new keybindings to do exactly that. It's not about whether other editors have certain abilities it's about adding the abilities you want or need to your editor.

I'm constantly learning new things about it after years of using it.

On windows I still use Notepad++ for simple, tiny edits for which I can't really justify spinning up an IDE. When I can I tend to stick with Jetbrains stuff (thank you, student products) like Webstorm, PHPStorm or Pycharm.

On Linux I still use Jetbrains, and occasionally Vim or just Nano if need be. I still tend to work a lot on Windows though so I haven't really settled on any editor yet.

I use Sublime Text 3 for programming due to its relatively lightweight nature and built-in support for many different languages, and nano for any command-line editing (e.g. modifying config files on a remote server) due to it being the simplest to use without the need for memorizing a bunch of keybindings while also coming pre-installed on the distros I work with (yes, I know that vi is significantly more powerful than nano, but it's very seldom the case that I need it).

wow I see there's a lot of code writers here haha def feel like the minority.

Visual Studio Code. Looks good, is open source, is actively developed, has all needed features.

The favorite feature is ability to open any folder as project and search text there. The drawback is, sometimes it refuses to show big files. Then Notepad++ comes to the rescue as a backup.

For editing, I'd have to say most things move beyond just my editor.

My shell is fish, for the awesome predictive commands, and the great shell language.

Fish gets extended by my manager, GNU Screen. Everything gets a screen session, and some things are attached to the same screen.

I do use nano for writing, it gets out of my way. But for common problem editing, I've got a couple dozen fish functions, ed scripts, and so on.

Though, for some things I go to Vim, which is usually also available.

I also use heredocs a surprising amount of time.

I used Neovim for about 6 months then switched to Emacs mostly because of Org Mode. After another 6 months, I am now a very satisfied Emacs/Evil user, and (except for quick edits with Neovim in the command-line) I'll use it for everything text related (including prose) unless I'm forced by some strong circumstances to use something else.

My gigantic configuration.

Depends, for quick edits I usually go with nano, but if I'm going to be writing something for more than a few minutes, I fire up vim.

I've never been quite a fan of TUI applications (I grew up with a mouse and later, a touchscreen), but if necessary I will use nano.

For text unrelated to a bigger project, like config files, I use Linux Mint's graphical text editor xed and for projects I employ geany, which is a comparatively light-weight IDE.

I use GNU Emacs for editing and beyond. Its customizability, interactivity and Elisp are just unmatched. I edit text and code in it, using Org Mode as an intermediate language for TeX and LibreOffice. My configuration.

I use nano in the shell and VS Code for my graphical editor.

Windows: for quick stuff, Notepad++, for long stuff, Vim.

Linux: for quick stuff, Gedit, for long stuff, NeoVim (NeoVim on Windows takes too long to load and can be unreliable).

I usually just use Sublime Text 3. I love the development pace of VS Code and I feel like Microsoft's doing a great job with that editor, but Electron apps just run so slow on my old and shitty laptop that I keep finding myself going back to Sublime. Course, it also helps that I'm used to all the keybindings.

I am unable to remember many things (commands, shortcuts, menu locations, etc.) so I usually go with whatever is the most intuitive available editor on whatever platform I have to use. On the command line I use nano and if that's not available I use vim (after years of practice I managed to learn the commands to save, quit, insert and remove lines, and copy and paste, that's all I need). If I can use a GUI I use Mouspad, Geany or Kate in no particular order of preference (for all of the them the shortcuts are the same, ctrl+s to save, ctrl+c and +v to copy and paste and ctrl+w to close a tab, I don't need more than that). TL;DR whatever gets the job done quickly and without making me have to learn and remember a million shortcuts.

Sublime text 3 for coding stuff

Vim for quick edits on the terminal, Atom for stuff I want to sit down and work on. I don't particularly like Atom but it works well enough. I might go back to VS Code. I just need the real mouse support and workflow of a GUI program. Vim tries so hard to have mouse support but it just gets in the way more often than it helps.

Depends on what I'm doing. Vim is great if I need to do something quick from the command line or if I'm SSH'ed to a remote server. For heavy development the JetBrains IDEs are fantastic, PhpStorm is my daily driver. For one-off local file edits or as a general scratch pad, BBEdit doesn't suck. Usually when I'm working with text I find formatting to be more annoying than useful, but if I'm taking more detailed meeting notes or documenting something non-technical Evernote gets the job done.

I still haven't been able to settle on a single editor.
For a while I have been using vim, then tried atom for a while but the startup time on it drove me crazy.
Currently I am shuffling between vscode and sublime text 3. The ui experience of vscode is nicer compared to sublime-text 3. But I have been enjoying sublimes keyboard shortcuts and find myself being more productive on it.

Kakoune! It's like Vim, but better! :)

The following is an abbreviated excerpt from "Why Kakoune?" which I highly recommend giving a click as it contains many useful visuals.

Improving on the editing model

vi basic grammar is verb followed by object; it’s nice because it matches well with the order we use in English, "delete word". On the other hand, it does not match well with the nature of what we express: There is only a handfull of verbs in text editing (delete, yank, paste, insert…​), and they don’t compose, contrarily to objects which can be arbitrarily complex, and difficult to express. That means that errors are not handled well. If you express your object wrongly with a delete verb, the wrong text will get deleted, you will need to undo, and try again.

Kakoune’s grammar is object followed by verb, combined with instantaneous feedback, that means you always see the current object (In Kakoune we call that the selection) before you apply your change, which allows you to correct errors on the go.

Kakoune tries hard to fix one of the big problems with the vi model: its lack of interactivity. Because of the verb followed by object grammar, vi changes are made in the dark, we dont see their effect until the whole editing sentence is finished. 5dw will delete to next five words, if you then realize that was one word too many, you need to undo, go back to your initial position, and try again with 4dw. In Kakoune, you would do 5W, see immediately that one more word than expected was selected, type BH to remove that word from the selection, then d to delete. At each step you get visual feedback, and have the opportunity to correct it.

At the lower level, the problem is that vi treats moving around and selecting an object as two different things. Kakoune unifies that, moving is selecting. w does not just go to the next word, it selects from current position to the next word. By convention, capital commands tend to expand the selection, so W would expand the current selection to the next word.

Multiple selections

Another particular feature of Kakoune is its support for, and emphasis towards the use of multiple selections. Multiple selections in Kakoune are not just one additional feature, it is the central way of interacting with your text. For example there is no such thing as a "global replace" in Kakoune. What you would do is select the whole buffer with the % command, then select all matches for a regex in the current selections (that is the whole buffer here) with the s command, which prompts for a regex. You would end up with one selection for each match of your regex and use the insert mode to do your change. Globally replacing foo with bar would be done with %sfoo<ret>cbar<esc> which is just the combination of basic building blocks.

…

Interactive, predictible and fast

A design goal of Kakoune is to beat vim at its own game, while providing a cleaner editing model. The combination of multiple selections and cleaned up grammar shows thats its possible to have text edition that is interactive, predictible, and fast at the same time.

Interactivity comes by providing feedback on every commands, the inverted object then verb grammar makes that possible, every selection modification has direct visual feedback, regex based selections incrementally show what will get selected, including when the regular expression is invalid, and even yanking some text displays a message notifying how many selections were yanked.

Predictibilty comes from the simple effect of most commands. Each command is conceptually simple, doing one single thing. d deletes whatever is selected, nothing more. % selects the whole buffer, s prompts for a regex and selects matches in the previous selection. It is the combination of these building blocks that allows for complex, but predictible, actions on the text.

Being fast, as in less keystrokes, is provided by carefully designing the set of editing commands so that they interact well together, and by sometimes sacrificing beauty for useability. For example, <a-s> is equivalent to S^<ret>, they both split on new lines, but this is a so common use case that it deserves to have its own key. As shown in http://github.com/mawww/golf, Kakoune manages to beat Vim at the keystroke count game in most cases, using much more idiomatic commands.

Discoverability

Keyboard oriented programs tend to be at a disadvantage compared to GUI applications because they are less discoverable; there is no menu bar on which to click to see the available options, no tooltip appearing when you hover above a button explaining what it does.

Kakoune solves this problem through the use of two mechanisms: extensive completion support, and auto-information display.

When a command is written in a prompt, Kakoune will automatically open a menu providing you with the available completions for the current parameter. It will know if the parameter is supposed to be a word against a fixed set of word, the name of a buffer, a filename, etc…​ Actually, as soon as : is typed, entering command prompt mode, the list of existing commands will be displayed in the completion menu.

Additionally, Kakoune will display an information box, describing what the command does, what optional switches it can take, what they do…​

…

Extensive completion support

Keyboard oriented programs are much easier to work with when they provide extensive completion support. For a long time, completion has been prefix based, and that has been working very well.

More recently, we started to see more and more programs using the so called fuzzy completion. Fuzzy completion tends to be subsequence based, instead of prefix based, which means the typed query needs to be a subsequence of a candidate to be considered matching, instead of a prefix. That will generate more candidates (all prefix matches are also subsequence matches), so it needs a good ranking algorithm to sort the matches and put the best ones first.

Kakoune embraces fuzzy matching for its completion support, which kicks in both during insert mode, and prompt mode.

…

A better unix citizen

Easily making programs cooperate with each others is one of the main strength of the Unix environment. Kakoune is designed to integrate nicely with a POSIX system: various text editing commands give direct access to the power of POSIX tools, like |, which prompts for a shell command and pipe selections through it, replacing their contents with the command output, or $ that prompts for a command, and keeps selections for which the command returned success.

…

Final Thoughts

Kakoune provides an efficient code editing environment, both very predictible, hence scriptable, and very interactive. Its learning curve is considerably easier than Vim thanks to a more consistent design associated with strong discoverability, while still being faster (as in less keystrokes) in most use cases.

…

Kakoune is available at http://github.com/mawww/kakoune and has a website at http://kakoune.org

Vim. It's awesome and there are plug-ins for almost everything.

Kate most of the time, Vim when needed.

Linux: nano for quickies, Emacs for more
Windows: NotePad++

Atom for serious programming, Vim if I just need to quickly edit a config file or write a script, Trilium for long term notes, and Gedit if I just need someplace to type/paste stuff into.

I use Altova XML Spy for well XML and XSD and I like it a lot. I'm not even remotely using all it's capabilities but it's very intuitive and I like the different views to see and edit your code.

GVim with about 15 years worth of accumulated .vimrc customizations that I keep in a special source control repo.

I was using neovim until yesterday. Switched to micro recently and i'm liking it so far.

Neovim and VsCode with VsVim

Spent a lot of time evaluating environments and forced myself to use vim exclusively for a month. Once I got used to the basics I never wanted to edit any other way and resent using stuff like the browser, Word/Docs or Excel/Sheets without vim keybinds. There are often things to emulate but none do it very well except the vim emulation in VsCode is close enough to justify using it especially for typescript development.

Not for a lot of years.

My favourite was the Vi editor. Talking late 1980's here. Anyone else as old as me??!!

Shift-ZZ: Out!

Nano for configuration/administration, and Sublime for more complex things like coding.

TextMate 2, primarily.

Nowadays, Emacs. It's FOSS, it's not modal, it's incredibly configurable and very lightweight when compared to the alternatives - Vim is out because of modal editing, Sublime (my old editor) is not FOSS, VSCode & Atom use Electron and I intensely dislike Electron and its RAM-gobbling ways.

I discovered Howl afterwards, but even if it took a while to get used to Emacs I now have configured my environment just how I like it, courtesy of Babel + Org-mode.

vim in the terminal and intellij/eclipse for java

https://www.xkcd.com/378/