Having trialled many text editors over the past few years, I'll say that for me, Scintilla-based text editors are the best, followed by Vi/Vim, standard Linux/OS bundled text editors, and as bottom of the heap emacs based lispy madness. Of those Scintilla-based editors, two in particular stand out for me: Notepad++ and Geany.
Having used both of these extensively, Notepad++ moreso (i.e. primarily on my laptop) and Geany mostly on Linux (since Notepad++ won't run there, though occasionally on Windows I'll use it too), I just find Notepad++ that much more productive to work in.
And here's why...
Text Editor "Quality" Ratings Scheme
Here is the list of features I look for in a text editor, some of which I consider "essential" to coding...
- Function List - this should be able to be shown as a dockable panel on the RHS of the screen. It means that you can easily jump to a definition of a function in your code by scanning down the list of function names and identifying the one you want, instead of resorting to using a search every time.
- LHS docking only is nasty, as it offsets most of the code to be in the middle of the screen (RHS docking only covers up long lines, which is ok with a little scrolling).
- Collapsed combo-list popup only function lists (a la Visual Studio) are lame and equivalent to defunct. It introduces an extra click to get at the list, not to mention additional navigational overhead getting around the list as it is shown quite small and with a dinky little scrollbar that can be easily missed
- No function list capabilities at all (i.e. not even a semi-decent plugin for this) are quite a nail in the coffin, restricting a text editor to small 100-line or smaller files, where it is used more as a quick view+tweak than for "serious" coding.
- Functions should be able to be listed in file-appearance order by default. There are places for alphabetically ordered lists, but I don't think this is one of them. By listing in file order, you can get a much better appreciation of the structure of the codebase and how functions related to each other. IMO, code should be ordered into logical chunks even within a file, with functions related to a certain activity or whatever being clustered together instead of being bisected by other unrelated chunks. People who don't use appearance-ordered function lists are more likely to just chuck functions in a file in any old place, resulting in some strange things (i.e. a section for object transform data conversion was bisected by a whole section for sequencer transform data, complete with a little comment header!)
- (NOTE: I'm currently still using an older version of Notepad++ - 4.6 - which serves me well, and is so far the last one with a working function list (at the time of writing). Due to difficulties sourcing a reliable function list for latter versions, I'll stick with this version until it refuses to run on some new hardware I think)
- Personally, I prefer being able to just click in the margin to set one, and click there are again to clear it. Once set, to be able to just jump between markers using a single-key hotkey.
- Many other editors that offer this usually have this set up so that adding a marker requires between 3 and 4 key presses (i.e. "Ctrl-M Ctrl-M" emacs-style incantations)
- Not having this functionality is just yuck! I'm
not convincedof the vehement opinion that "history jumping" is an inferior hack that just tries to rely too much on short-term memory of temporal transitory state orders (translation: it only works if you're a history major).
- I'm unsure whether Geany still has this. On my copy here it still works (and always has), though in Linux labs at Uni, this doesn't seem to exist anymore (IIRC those used a more recent version).
- Having used these for quite a few years now, seeing code without them seems a bit "bare". No wonder some people have a thing against indention (i.e. probably the same delusional crowd that swears by spaces)
- Usually the option to preserve this indention is called turning off "Strip trailing spaces". IMO, this option is nearly universally implemented incorrectly: it should be a 3-phase instead of 2-phase FSM, with an initial "indention" step (which IMO is usually omitted) which goes until the first non-whitespace character on the line (i.e. first bit of code). Under this scheme, only the whitespace AFTER the end of the code-text, which would be in the 3rd-stage of the parsing, should get stripped, as I do agree that that is validly problematic (i.e. it breaks multi-line C-macros for example).
- If indention on such lines is preserved, when navigating the code your cursor doesn't suddenly "disappear" (i.e. shoot off hard to the left) every time when encountering a line with no indention whatsoever while navigating through a function. This is quite distracting, and makes navigation line-by-line feel worse than it should. Alarmingly, this is in one of the text editors where line-by-line navigation ends up being nearly the only reliable navigation mechanism, and which also refuses to preserve indention no matter what settings you throw at it (NOTE: when asked about this, community members of this text editor staunchly defended this limitation as a "why would you ever want that?!", trying to use a reverse logic of the above to try and defend their case.)
- Where working with tab-indention is not possible, such as on public Python source code (IMO, wrongly) indented using spaces, an additional option for being able to use the existing indention style of the file in question is useful (though new files still get set with tabs). This is my main use for Geany on Windows these days.
- http://aligorith.blogspot.com/2010/09/matters-of-code-indention-tabs-only.html - 'nuff said.
- Side rant: my personal guideline on splitting long lines is to only split if the first line is longer than ~3 inches, and that by splitting the line, you'll have another line which is at least 2 inches wide. Otherwise, that last factor can just go on that top line as well no problem.
- Although the school of thought which things that we should have separate tools specialised for particular tasks has merit, I think that we should not have to rely on having a separately installed grep too (or other code browser) installed just to get this type of functionality.
- By carefully setting your filetype filters (i.e. *.c to search for C source files only, thus avoiding any SVN backup copies in .svn subdirectories along the way) and restricting the search to start from a particular directory (but not restricting it to that directory only - i.e. "recurse into subfolders" on), this can be quite efficient. Geany's reliance on grep makes this somewhat more difficult (including requiring a hack to make it avoid svn directories, but which still doesn't totally work)
- Notepad++ has a dedicated Search Results pane which appears when needed and can be easily dismissed with a single click. Geany though has an horizontal tabbed panel that doesn't go away unless you drag it out of the way (collapsed) and then have to drag it back up later to see search results. Also, choosing a search result causes the tabs to change, needing further clicks to get back to the search results again.
- In Notepad++, this is simply Ctrl-D. I've customised Geany to do the same (IIRC it had the functionality, just no shortcut)
- IIRC, in Vim, you can do this with yyp (?)
- Ideally the colours shouldn't look too garish, in combination and also in isolation. However, this is less important, as we can always fix this
- Automatically added brackets/braces usually turn out to be too much of a hindrance, especially when trying to add them around some existing code in the middle of a line.
- Being able to show these matches can help figure out weird parsing errors at times
All of the above features are useful features in Notepad++ that I make quite extensive use of, and which IMO are some of the reasons for efficiency.
Having said that, today I found some new tools that are very useful for some things I find myself doing quite a bit.
- "Transpose" lines - Ctrl-Shift-T - this just swaps the current line with the one above it
- "Move current line up/down" - Ctrl-Shift-Up/Down - this just moves the current line around as mentioned