I've noticed that if you add "and not much else" to a list of desired features, you end up shooting yourself in the foot. This applies to almost anything that you can get off the shelf.
There seems to be a common pathology among computer programmers to hate "superfluous" features in their tools and libraries. I'm not talking about people who are skeptical of potential complexity, but people who dismiss outright solutions that meet their specifications closely because of the extra baggage they don't like. This attitude has spawned a number of cool, lightweight tools, but it's also wasted a lot of time that could have been spent doing something more productive, like memorizing Pokemon.
Like, "Emacs is too big." Yeah? But Firefox isn't?
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?
Wider range of usable keybindings. Potentially more expressive syntax highlighting. Multiple font/size usage, which some themes make good use of in some modes. Inline images in org-mode (and eww?). Reading PDFs.
All I want, in any text editor, is multiple cursors [1]. It's a really powerful concept that renders a large number of otherwise tedious operations tractable without having to resort to macros or other nonintuitive abstractions.
I feel like it's such a useful feature that it should be baked into your operating system's text field widgets from the ground up. It's intuitive enough, too, that regular users could probably grasp it.
While I'm here I'd like to gripe that while there is a third party Atom package which adds support for multiple cursors [2], it has a number of bugs in it which seem to be irresolvable due to some deep architectural issue with Atom. ARGH.
You can open random files with it. From the command line, type `idea <filepath>`. If you already have a project open, the file will open in the same window as that project, but it isn't tracked as part of the project. If you don't have IntelliJ open yet, it starts a new instance with just that file.
That being said, even though I'm more comfortable with Jetbrains' editors, I still tend to edit miscellaneous docs in atom or vim.
Maybe. You can get multiple cursors in Vi(m) too. Essentially it's just an interactive way of applying a particular set of commands in more than one place in a file. Personally I've never actually used it and not regretted writing a regex to do it instead.
I navigate almost exclusively by keyboard and I use multiple cursors in Sublime Text constantly. Maybe a better term for it would be "multiple carets".
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.
That makes sense. I use RubyMine's refactoring to rename all instances of a variable, but if that weren't available multi-cursor would certainly be a lot easier than copy-pasting.
> refactoring (select a variable name, select all instances of that name, change),
regex works great for me in vim
> 1 time pre-processing data
I use regex for this most of the time, and macros if it's more complicated. I think macros are actually quite a bit more powerful than multiple cursors because you can apply the same set of transformations between files (and without needing to match against a particular word or pattern).
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.
"Mono-spaced fonts are an anachronism as far as I’m concerned; text is easier to read when it’s spaced properly. This is certainly true for my text heavy documents, like this article, but I also prefer to code this way."
I've never met anyone who codes without a fixed-width font. Has anyone here tried it? What are your experiences?
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.
Sublime Text is the better option right now. Atom is still (too) slow. Can handle pure programming, remote files over ssh, [1] complex builds, and act as a one-stop-shop for all your writing needs. [2]
[2] My personal experience/setup: write in Markdown, export to pretty much every file format using Pandoc (binds nicely with a ST package) and custom Pandoc builds/templates. For instance, I export native Markdown to Tufte Handouts LaTeX-generated PDFs. Love this.
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 gets a bad rep for the complexity and learning curve, but I have seen new users adapt Spacemacs[1] pretty quickly. Emacs may be not the best text editor after the first week of usage, but after months or years there is nothing like it, especially when you learn elisp. I almost live in Emacs nowadays. I agree that vim key bindings are more efficient and I use evil mode[2] myself, but Emacs does everything except pure text editing better, regardless if you use vim or neovim.
Personally, I want a smarter editor with more precision and less typing, even if it's difficult to learn. Many developers spend a couple thousand hours a year in an editor.
The editor should be a precise tool.
For example, AceJump for smart navigation can be found in several editors.
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.
If you use Neovim (or even stock Vim), you can do everything you want. Proportional fonts are a bit harder because you'd need to change your terminal font, but presumably you could do it within gvim. Not that I understand the logic behind wanting proportional fonts for _programming_.
Well, since we are stating what we want in an editor, my most wanted feature is fuzzy autocomplete on everything. Functions, variables, whatever. It must understand the context, so if I am about to call a class function on a class, it should only give suggestions that are in that class. It must be fuzzy, because I want to type whatever letters in a row I want, and if it exists in the name, it should suggest it.
This mostly needs compiler/linter/interpreter support. I want it to just work. It should detect the language I'm using, and just search/download/connect everything up so I have my awesome fuzzy autocomplete.
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.
Though I'm a pretty heavy emacs user, I have a great backup suggestion that I've really been enjoying: Visual Studio Code.
MS has built a really great editor for lighter text work. Markdown editing with it is great and language support is getting better each release. Actually most features of it are getting better with each monthly release. I've been very pleasantly surprised with it. It's been gaining a number of begrudging converts at work who use it on their MacBooks as an alternative to Sublime.
48 comments
[ 6.0 ms ] story [ 97.3 ms ] thread(Not if you run it in a terminal, sure, but why would you want to do that?)
There seems to be a common pathology among computer programmers to hate "superfluous" features in their tools and libraries. I'm not talking about people who are skeptical of potential complexity, but people who dismiss outright solutions that meet their specifications closely because of the extra baggage they don't like. This attitude has spawned a number of cool, lightweight tools, but it's also wasted a lot of time that could have been spent doing something more productive, like memorizing Pokemon.
Like, "Emacs is too big." Yeah? But Firefox isn't?
[0] http://ranger.nongnu.org/
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 feel like it's such a useful feature that it should be baked into your operating system's text field widgets from the ground up. It's intuitive enough, too, that regular users could probably grasp it.
[1] As per Sublime Text: http://www.sublimetext.com
While I'm here I'd like to gripe that while there is a third party Atom package which adds support for multiple cursors [2], it has a number of bugs in it which seem to be irresolvable due to some deep architectural issue with Atom. ARGH.
[2] Sublime-Style-Column-Selection is the only package that attempts to do it "properly": https://atom.io/packages/sublime-style-column-selection
https://www.jetbrains.com/help/idea/2016.1/multicursor.html
That being said, even though I'm more comfortable with Jetbrains' editors, I still tend to edit miscellaneous docs in atom or vim.
regex works great for me in vim
> 1 time pre-processing data
I use regex for this most of the time, and macros if it's more complicated. I think macros are actually quite a bit more powerful than multiple cursors because you can apply the same set of transformations between files (and without needing to match against a particular word or pattern).
In emacs, there's also iedit-mode, which is another way of doing the same sort of things you would do with multiple cursors.
I've never met anyone who codes without a fixed-width font. Has anyone here tried it? What are your experiences?
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.
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.
Editors are definitely starting to get there, with colour support coming along, but there's a long way to go.
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)
[1] http://log.liminastudio.com/writing/tutorials/sublime-tunnel...
[2] My personal experience/setup: write in Markdown, export to pretty much every file format using Pandoc (binds nicely with a ST package) and custom Pandoc builds/templates. For instance, I export native Markdown to Tufte Handouts LaTeX-generated PDFs. Love this.
http://www.scintilla.org/SciTE.html
It's still relatively early in development, but it's both no-nonsense minimalistic and crazy customizable.
1. http://spacemacs.org/ 2. https://www.emacswiki.org/emacs/Evil
The editor should be a precise tool.
For example, AceJump for smart navigation can be found in several editors.
https://www.youtube.com/watch?v=UZkpmegySnc
Ideally, we would augment the keyboard with eye-tracking for navigation, Leap Motion hand tracking, and voice programming:
http://ergoemacs.org/emacs/using_voice_to_code.html
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. :-)
This mostly needs compiler/linter/interpreter support. I want it to just work. It should detect the language I'm using, and just search/download/connect everything up so I have my awesome fuzzy autocomplete.
Why is that not a thing?
There are projects like https://github.com/Valloric/YouCompleteMe and other ones for Vim and Emacs, but they are not yet what I want them to be.
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.
MS has built a really great editor for lighter text work. Markdown editing with it is great and language support is getting better each release. Actually most features of it are getting better with each monthly release. I've been very pleasantly surprised with it. It's been gaining a number of begrudging converts at work who use it on their MacBooks as an alternative to Sublime.