I'm curious, what features make a text editor "decent"?
Well... quite a lot, really. I mean, there are hundreds, maybe thousands, of essential functions a text editor requires. It needs an infrastructure for handling text, files, buffers, window management, keymaps, history, registers, macros, syntax highlighting, user interaction, etc, etc.
I suppose the most important is the ability to customize the editor to suit your needs. You should be able to customize all aspects of the editor in real time, in a real programming language. It should have a system of modes to make it easy to switch between different keymaps and behaviours. There should be hooks for important events, so behaviour can be added in a systematic way. Additionally, editor functionality should be exposed as functions which can be replaced or advised if required. The various parameters controlling editor behaviours should be able to be overridden when required (some type of dynamic scoping is useful for this purpose). And obviously, all keybindings should be rebindable to arbitrary functions.
To be able to use a powerful editor, a powerful help system is a also a must. If you need to know the function a key (combination) is bound to, or what that function does, or you need to see its source, that should be quick and easy to do.
Basically, if you want to do something text-based, and you know how to do it, you should be able to instruct the editor to do it, without any undo hassle (which is likely to prevent you from actually doing it).
I suppose your average "modern" text editor is well-designed for someone who only uses an editor lightly and won't bother adding custom behaviour, but I wouldn't want to use one. When the editor (or an extension) has behaviour you don't like, you often just have to put up with it. And you can't add arbitrary behaviour without going through whatever arcane ritual they've decreed for building extensions. (And I just know that if I did go to the trouble, I still
wouldn't have free reign - these editors simply aren't designed to be extensible.)
The thing is, I type in Dvorak but use a keyboard setting that allows me to use standard keyboard shortcuts. So even though the "C" key on the keyboard will actually type a J, when used in a keyboard shortcut it will work as a C and allow me to Command-C for Copy. This only works with the Command key though, not the Ctrl or Option keys if used without the Command key. And it doesn't work in all programs. For instance, when I work in Photoshop or InDesign I just use QWERTY layout so all the keyboard shortcuts work the way they are labelled in the menus. That's not a problem, because I'm not usually doing much typing in those programs, mostly mouse work and so forth. In a text editor, it becomes much more of a nightmare.
But actually that's only half of the problem. Even without my odd keyboard preferences, there are still issues. Nearly all of the standard Mac text editing keyboard shortcuts do something else in Aquamacs. These are: Command-left or right to move to beginning or end of the line, option-left or right to skip by words, command-up or down to go to beginning or end of the file, option-up or down to skip up and down by paragraphs, and hold down shift with any of the above to highlight instead of moving the cursor. And yes, I routinely use Command C, X, V, Z, A, S, Q, W, and also Command F...the list goes on. These are all standard Mac shortcuts for text editing. They ALL work in TextWrangler.
I'm surprised at the movement shortcuts being different. I could swear they were always very similar for me in (vanilla) Emacs. (I've changed most of them because I never use them for their original purpose in an editor). Although it sounds like they're a bit different on OS X? So in OS X, Command==Super and Option==Alt, but Command is often used in place of Ctrl in combinations? I'm sure on Linux and Windows, Ctrl-left/right moves by words, Ctrl-up/down goes by line beginning/endings, Home/End goes to the beginning/end of the current line (idempotently), Ctrl-Home/End goes to beginning/end of file and shift adds selection. I think Alt-movement is usually reserved for the application (at least on Linux).
Personally, I use vi and/or emacs bindings for everything, which I find works a lot better than trying to accomodate CUA bindings. But you can change the bindings to suit your preferences. Chances are, there's a config available to restore the default OS X bindings. Probably one for converting dvorak bindings too. Maybe not for the combination, though. Still, it's easy to change whatever bindings you want. I won't go into detail now since you've decided not to use Aquamacs, but basically to set Alt-right to go the end of line, you'd start with C-e
(the current end of line key), do "C-h k C-e
" to find what it points to (it'll say "end-of-line
"), then add "(global-set-key (kbd "<M-right>") 'end-of-line)
" to your init file. (M-
is Emacs for "Alt"). If you hit C-x C-e
at the end of the line (in any Emacs lisp buffer), you'll execute the line, so you can check it's working.
Personally I couldn't live without Visual Studio + Resharper + NCrunch plus other plugins like Greenkeeper which allows one-click, automated rearrangement of properties, methods and the like into alphabetical order, newspaper mode and so on
Methods into alphabetical order? That's very... orderly.
Well, I don't know why you'd want to, but once you've got a parser, that's trivial. What's newspaper mode?
Resharper allows for project-wide refactoring, code quality enforcement (ie. does it follow company standards) and too many other benefits to list.
I know everyone who uses VS loves Resharper. I suppose it must have something going for it. I've always been a bit dubious about how powerful an IDE extension could be as a refactoring tool, though. Refactoring is just so... general. I haven't given it much thought, but the one conclusion I have is that the right way to offer a rectactoring solution would be as a library
. It seems to me an IDE extension would need to implement its own programming language to do a good job.* My assumption is that Resharper must identify a very limited but useful class of refactorings and make those as easy as possible. That would certainly be worthwhile.* And ideally its own editor, for that matter, since some refactorings are inevitably going to require extensive user interaction, even if they're software-aided.
I'm curious about this. Refactoring is something I'm not efficient enough at (I just use general editing mechanisms). Which is bad, because it means I'm less likely to do it. I've been meaning to check out the available tools. What kind of refactorings does Resharper allow? I assume it does stuff like renaming and moving stuff around. But what else? And why does it make it so much easier?
Sounds like a pain in arse.
allows for continuous, real-time unit testing with errors and code-coverage failures shown inside the code itself as you type it (great for TDD)
Well, IDEs would have a slight presentational advantage, but I can't really see the difficulty in setting up whatever tests you want in an editor. Automation is what editors are good at (as well as, you know, editing).