The simple things I want in a text editor

It's not a simple text editor but Jetbrains editors fully support this and I LOVE it! Agree with you 100% that it should be in everything.

https://www.jetbrains.com/help/idea/2016.1/multicursor.html

Is multiple cursors like setting marks in vi?

Now that I'm used to keyboard navigation this seems so backwards

What do you actually use multi-cursor for in typical coding? I tried it out when it was introduced in IntelliJ. I thought it was cool, but I've not run into any uses for it in the years since.

Obligatory emacs: http://emacsrocks.com/e13.html.

When I remember to use multiple cursors (in emacs), they work really well, but also seem kind of gimmicky. Anything you can do with multiple cursors (at least as they exist in Sublime Text and emacs multiple-cursors-mode) you can also do in emacs with a keyboard macro, and I got into the habit of using keyboard macros a long, long time ago.

In emacs, there's also iedit-mode, which is another way of doing the same sort of things you would do with multiple cursors.

It was horrible and I stopped as soon as I could.

Proportional fonts are great for reading, but awful for debugging, because character recognition isn't the same process as reading text. Not in my brain, anyway. Typos that I would normally catch before moving on to the next statement went undiscovered until compile time.

I tried it for about a week and went back to monospaced. It wasn't a very pleasant experience. Code and prose are very different things. Special characters are very significant when programming, and tend to run together and be hard to read with a proportional font. Double space indents are hard to follow, and alignment beyond indentation is hard to get right.

It might be workable if you're working exclusively with your own code using tabs for alignment, but that's a luxury not everyone has.

I've met people who do this. It only works in some languages. The status quo is certainly to use a fixed-width font and many people's formatting habits depend on this. Very quickly it isn't worth the trouble. Seeing it in action though I think it will be the long-term outcome. I suspect the use of text to provide structure will subside in the next few decades. We have better user interface tools now. Light table and some others have demonstrated this. In that environment variable names and strings could be rendered in a regular font. I suspect this would be much more pleasant to read if structure was maintained consistently outside the font.

It's works fine if you avoid/work-around ASCII art, use tabs for indentation, and only align code by indentation which has merits when coding even in monospaced fonts.

I'd really love to do this, but there isn't a single editor I know of that can do it well. Because, for me, the trick would be to have different fonts and styles to help give the code context. Eg, the line defining a new method should look like a sub-headline, while the contents of a comment should look like a quote, variable names in italics etc.

Editors are definitely starting to get there, with colour support coming along, but there's a long way to go.

He uses his editor to work on texts. Then I can understand that he wants to have non mono-spaced fonts. However that would work for the text, not for the code. So there should be a mechanism to make up the code, like with color coding, and use a different font for text if it's just text, not code.

For people who would like to test and report back, there is this http://input.fontbureau.com/info which apparently is a proportional coding font. I have never used it. I like my monospace fonts, even for reading.

I learnt to program in 1990s at Glasgow University with the same team who created Haskell. We programmed (in Pascal and Haskell* ) with proportional fonts, bold, italics and tabs. Later we had to use literate style: the essay documents (by now in LaTex) could be run as code was tagged and everything else was a comment.

As I recall, if you handed in a proportional printout your assignment was marked down if marked at all.

With high res screens and beautiful on-screen fonts (on Macs & Suns) it only seemed natural at the time. In my opinion it was the arrival of Linux at home with tiny monitors and low-powered PC (coupled with a slightly macho overemphasis on editing in the command-line and a disdain for GUIs) that took us back to proportional fonts.

Shame.

* Actually, Gofer, Mark Jones's variant. https://en.wikipedia.org/wiki/Gofer_(programming_language)

Atom looks cool, but is way too slow.

Not the author, but I'm guessing what he means is that he wants a simple text editor that covers his required features and not much else.

I use ranger [0] as a file manager. So I want to run any text editor in a terminal! In order to keep consistency with the many advantages of ranger.

[0] http://ranger.nongnu.org/

Not only that, but the list in the original article describes the defaults in a completely unconfigured Emacs installation.

If the argument is that Emacs supports other things as well, then I have nothing to reply. I find it bizarre that someone would complain about features that they font have to use (as someone else already mentioned in this thread).

I run emacs almost exclusively in a terminal (-nw) because part of my move to emacs was the intention to be used to fully operating from a term. Any particular reason I should consider the x gui version?

That's basically Notepad++, which us Windows folks tend to use pretty heavily. Notepad++ does pretty much everything on this list, even the questionable choice of using non-monospace fonts, although that is kind of a PITA to change from the defaults.

Emacs helm mode: https://github.com/emacs-helm/helm .

In Emacs, usually a language support library (like ensime, ycmd or ggtags) just give you a list of things user can choose from. This list is often passed to a function like completing-read. You choose the implementation for complete-read. Helm is a very good option for fuzzy matching implementation. There are more advanced options like icicles, that let you switch between completion modes (including fuzzy) on the fly.

Or Geany (since the author is using Ubuntu)?

Eye-tracking is actually rarely what you really want. The problem is that it tends to cause severe eye strain in a short amount of time as you manually take control of your eyes and overtense your muscles.

Try visually typing out a sentence on a keyboard by looking at the keys in sequence as a demonstration. Your eyes naturally will want to be imprecise and move away from the points you care about, which will cause you to fight the tendency to saccade, creating both visual disturbances and muscle fatigue.

Eyes are meant for looking, not pointing. :-)