Notepad++ Text Editing Tips (and Text Editor evaluations)

Choice of software is largely quite a subjective matter, though the use of some software in particular can get pretty religious, in particular, text editors.

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...

1. 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)
2. Easily settable line markers - being able to mark a line as being of interest so that you can jump back to it later is pretty much essential. As well as using it to identify chunks of code that will need modification later while scoping out a change, it also has uses when trying to navigate some foreign code, figuring out which parts are useful for what you're doing by helping keep track of points where interesting stuff happens.
• 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 convinced of 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).
3. Indention guides - basically, these show you how many levels of indention you've got on each line, allowing you to very easily see and not just count the depth of indention. This does wonders when trying to line up chunks of code and to see the relative scopes of things, as having these guides forming columns down the screen show very quickly when something is wrong.
• 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)
4. Preserving indention on lines "without code" - as soon as you have the above feature, it becomes very obvious when whitespace "blank lines" are truly blank. They're like blinding flashes of light, tearing apart the fabric of the surrounding code. 
• 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.)
5. Indention should be able to be made in terms of tabs, with the display of these tabs being able to be customised so that they are shown with a width of 4 sw (space-widths) as opposed to the traditional and overly bloated (and hence possible origin of tab-hating schemes), and these tabs for indention being reliably handled consistently.
• 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.
6. Ability to turn off word-wrapping guidelines - I don't buy into the whole "80 char line limit" stuff. Sure, really long lines aren't too nice, but strictly chopped text is just as bad. Really, you should be able to guess visually what feels comfortable to read for one block of code vs what is ok as a generic standard reference based on ancient and hopefully increasingly infrequently used legacy constraints.
• 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.
7. Find in Files - being able to search for expressions within files within the neighbouring directories is useful for finding other uses of some changed code. IMO, used properly, it makes an IDE with projectfiles + autocompletion redundant. I prefer Notepad++ over Geany in this regard for the following reasons:
• 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.
8. Simple "Duplicate Line" tool - at some point or another, you're going to need to create some kind of repeated structure, be it a static struct array definition or an enumeration list with a certain prefix structure. Hence, being able to duplicate lines with a simple hotkey combination is very useful (instead of doing a select line, copy line, make space, paste line)
• 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 (?)
9. Large list of supported languages + syntax highlighting schemes - this just makes things easier to work with.
• 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
10. Can read files with any line-ending style - this isn't a problem for 99% of the editors out there anymore in modern times (sans MS Notepad) though it's worth noting this as it is still an important consideration as an "essential" feature
11. Bracket-brace matching - I prefer the highlight-only style instead of the auto-add style. 
• 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

Useful tips for Notepad++
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.

1. "Transpose" lines - Ctrl-Shift-T - this just swaps the current line with the one above it
2. "Move current line up/down" - Ctrl-Shift-Up/Down - this just moves the current line around as mentioned