This was a question in a newsgroup today: given the choice, is it better to test for multiple matches of a regular expression or to let the expression match multiple captures at the same time. My reply was that I thought multiple captures might involve less overhead in the regular expression engine because the capture matching is an intrinsic part of the engine algorithm, while finding multiple matches means running the expression against the input multiple times. But then I thought that the final outcome would depend much on the implementation details of the engine at hand, because there are a lot of other factors in favor of both approaches.

For example, expressions matching multiple captures tend to be a lot more complicated than those looking only for a single match. This could mean that multiple captures wouldn’t be as fast as one could think. Plus, the engine will be looking for multiple matches whether or not it will find any, this could slow down the multiple captures approach further.

Finally I thought that a carefully implemented engine wouldn’t probably show a great difference between the two approaches, but that I wouldn’t be surprised if any given implementation would actually show a sizeable difference. To find out how the .NET implementation performs, I did the following test.

I had a simple input string: one two three four five six seven eight nine ten . This string was matched first against the simple match expression [^\s]+ , which would return one match per number string, and then against the multiple capture expression (?[^\s]+ )*. The code then checked that in each case exactly ten matches/captures had been retrieved and that the content of the matches/captures was correct. This complete test was performed 1000000 times for each approach.

The result is interesting. The multiple match approach took 11.80 seconds to run a million times, while the multiple capture approach took only 8.46 seconds. So although the multiple capture algorithm has one more significant line of code (the one where the group is retrieved from the match by its name), it’s significantly faster than the multiple match approach.

I’m not completely sure if this result will be the same with expressions of varying complexity, but the difference is that large that I think it supports my initial idea about the nature of the algoriths involved in both approaches.

The test program I used wasn’t extremely long, so I thought in case someone wants to do his own testing I’d publish it here. Here you go:

class Program {
  static readonly string input = "one two three four five six seven eight nine ten ";
  static readonly string simplePattern = @"[^\s]+ ";
  static readonly string multipleCapturePattern = @"(?<entry>" + simplePattern + @")*";
  static readonly int runCount = 1000000;
	
  static void Main(string[] args) {
    Measure(new MethodInvoker(MultipleMatches), "Multiple matches");
    Measure(new MethodInvoker(MultipleCaptures), "Multiple captures");
	
    Console.ReadLine( );
  }
	
  delegate void MethodInvoker( );
	
  static void Measure(MethodInvoker methodInvoker, string name) {
    DateTime startTime = DateTime.Now;
    methodInvoker.Invoke( );
    TimeSpan duration = DateTime.Now - startTime;
	
    Console.WriteLine("Process '{0}' took: {1}", name, duration);
  }
	
  static void MultipleMatches( ) {
    Regex regex = new Regex(simplePattern, RegexOptions.None);
    for (int i = 0; i < runCount; i++) {
      MatchCollection matchCollection = regex.Matches(input);
      Debug.Assert(matchCollection.Count == 10);
      Debug.Assert(matchCollection[0].Value == "one ");
      Debug.Assert(matchCollection[1].Value == "two ");
      Debug.Assert(matchCollection[2].Value == "three ");
      Debug.Assert(matchCollection[3].Value == "four ");
      Debug.Assert(matchCollection[4].Value == "five ");
      Debug.Assert(matchCollection[5].Value == "six ");
      Debug.Assert(matchCollection[6].Value == "seven ");
      Debug.Assert(matchCollection[7].Value == "eight ");
      Debug.Assert(matchCollection[8].Value == "nine ");
      Debug.Assert(matchCollection[9].Value == "ten ");
    }
  }
	
  static void MultipleCaptures( ) {
    Regex regex = new Regex(multipleCapturePattern, RegexOptions.None);
    for (int i = 0; i < runCount; i++) {
      Match match = regex.Match(input);
      CaptureCollection captureCollection = match.Groups["entry"].Captures;
      Debug.Assert(captureCollection.Count == 10);
      Debug.Assert(captureCollection[0].Value == "one ");
      Debug.Assert(captureCollection[1].Value == "two ");
      Debug.Assert(captureCollection[2].Value == "three ");
      Debug.Assert(captureCollection[3].Value == "four ");
      Debug.Assert(captureCollection[4].Value == "five ");
      Debug.Assert(captureCollection[5].Value == "six ");
      Debug.Assert(captureCollection[6].Value == "seven ");
      Debug.Assert(captureCollection[7].Value == "eight ");
      Debug.Assert(captureCollection[8].Value == "nine ");
      Debug.Assert(captureCollection[9].Value == "ten ");
    }
  }
}

Here we go with another editor test, this time I took a look at EditPlus. You can find the introductional posting to this series here.

EditPlus is a commercial product by ES-Computing and it’s available from www.editplus.com. The version I tested was v2.12 (76).

First impressions

This program manages to show me two separate warnings on first startup, about the fact that I’m not a licensed user of the program. Why can’t they just let me get started with my 30 days evaluation without bothering me with this from the word go?

EditPlus installed a few start menu shortcuts and opened the link window after the installation was complete. That’s what made me click on their readme file, which I probably wouldn’t have seen otherwise. The interesting thing is that the readme has an English part and a part in “Hangul (Korean)”, a language I’m not familiar with. What surprised me, though, was that the Korean part displayed only cryptic ASCII rubbish instead of nice Korean characters. By going to a link that was listed in that paragraph (http://www.editplus.com/kr) I was able to confirm that my system has everything installed that’s necessary to view this language correctly. So, the first impression is that EditPlus doesn’t appear to have any Unicode support - or can it be that the makers forgot about that when writing up their readme?

The last thing I noticed immediately is an aesthetic aspect: I recently changed my Windows XP theme to the (more or less) new Royale theme by Microsoft. This seems to be a problem for the menu system in EditPlus, because every single entry in the menu bar has a background that’s noticeably lighter than the surrounding colour. I double-checked the same thing with the two editors I previously tested (UltraEdit and TextPad) and I found that both of them have the same problem! Interesting…

General features

EditPlus starts up very fast. The document model is MDI with an additional button bar at the bottom of the window, that allows to switch directly between loaded files.

While looking at regular expressions support, I found an interesting bug: I have a file starting with a line that says “Oliver Sturm”. Now I was searching for ([^\s]+) and the first match I got was Oliver Sturm (note that the space between the words was included). Searching for the next match, I got this: Oliver Sturm. It was not possible at all to match the complete line with the complete test expression ([^\s]+) ([^\s]+).
I sent this information to support and got a quick answer: EditPlus doesn’t support the \s placeholder. I looked at the documentation (hm - could have done that earlier ) and found that there’s no support at all for this kind of placeholder, neither for \s nor for \w, \d and the many others that are common. While TextPad (see previous test) at least offered supported for the Posix placeholder syntax, which is less comfortable to use but just as effective, EditPlus just doesn’t have any of those.

To cut the story short, I got a part success when I tried replacing the expression ([^ ]+) ([^ ]+) by \2 \1. This worked, but only after I switched off case sensitivity in the Find/Replace function. Apparently this is a bug, I’ll update this post with information when I get it from EditPlus support.

Multi file searching is supported, but replacing is not.

Word wrapping can be switched on and off easily, via a standard toolbar button or a keyboard combination. It’s also possible to configure toolbars to include any of the standard menu entries. It’s not possible to create new user toolbars, nor can additional commands, like commands to toggle a specific option, be used.

Scrolling and redrawing is normally extremely fast. The only thing that drags this down a bit is if word wrapping is on for a really large file - in this case, a status bar appears in the lower left corner of the window, showing how EditPlus is recalculating the wrapping of those lines that are too long. This happens for example when resizing the window, all the time, that is, which can be a bit disturbing. Interesting enough: with a very “wide” file, one line with around four million columns, scrolling and redrawing is just fine, even if word wrapping is on.

Memory allocation in EditPlus is a funny thing. I have this XML file in two versions, one with line feeds and indentation, nicely readable, the other with all the XML on one line. The readable file is slightly larger at 3.8MB, compared to 3.6MB for the compact one. Now, when loading the compact file into memory, Process Explorer shows the working set of the process growing by about 4MB. A nice number, without too much additional overhead. But when I load the nice version of the file, I see that this takes me about 15MB of memory! Huh?

Well, part of this is overhead that has to do with word wrapping, believe it or not. Word wrapping is on by default when loading this file, and switching it on and off lets the working set value shoot up and down by 4MB. 4MB RAM for word wrapping? Wow. A quick calculation: the file has about 132500 lines, 3850 of which are wrapped when word wrapping is on. I assume that for a line that’s not wrapped, only that information has to be stored: not wrapped. That’s a byte, or hell, let’s say four bytes. So roughly half an MB is gone on that. Which makes it 3.5MB for the wrapped 3850 lines, which is 909 bytes per line. Whoa.

Obviously, this doesn’t explain where the additional 7MB of RAM go - and did I mention that RAM usage goes down when switching word wrapping for the one line-file, too? Saves another 400KB or so on that one…

Sadly, EditPlus doesn’t seem to have any support for Hex editing.

Big file support is another thing in EditPlus that’s not as it should be. My normal test file has around 612MB, which is normally not a problem to load into my 2GB of RAM. When I tried to load this file, I got a message from EditPlus telling me that there was a file size of 511MB.

Things didn’t get better from there. I cut the file a bit to get it just under the magic limit of 511MB. Loading it failed nevertheless, with EditPlus crashing after using about 1GB of RAM - at this point, the status bar showed a load progress of 46%. I tried freeing even more RAM and the effect was that it took more than 1.2GB before crashing. EditPlus was the first among the editors I have tested so far that didn’t manage to load a large file like this.

EditPlus is easily usable with the keyboard, with the same potential restrictions that the toolbar configurability suffers from. It’s possible to configure keyboard shortcuts for every menu command via the Preferences dialog.

The only function that can pass for an editing helper is the Reformat command. This command will recognize the indentation depth of a paragraph of text and reformat it to break at a specific column. In the process, it kills any more fancy formatting there may be

EditPlus supports all three variants of line feeds and allows to switch them for any open file. It’s also possible to use a so-called converter when loading or saving a file - these are available for UTF-16 (called Unicode, once again), UTF-8, UTF-7 and a variety of code pages. Not quite complete, but nicely implemented. On the other hand, I was unable to load the aforementioned readme file with any of the Korean converters, so that I could have seen the Korean text in it correctly. It’s possible that I’m doing something wrong here, though.

EditPlus settings are another peculiar thing. Directly from the application, it’s possible to set the “INI File Directory”. There’s even an extra menu entry for that, as if I was going to do it all the time. Interestingly, the default path is the EditPlus directory underneath Program Files… what if I hadn’t had write permissions there? How about using \Documents and Settings\{username}\Application Data, guys?

The settings themselves seem to be distributed across a few ini files in the configured path and the registry. This is exactly what I meant when I included this point in my requirements list… this is how it should not be done.

System integration

The GUI of EditPlus is moderately modern, but it could definitely benefit from a facelift. The icons look extremely simplistic and some of them are really non-standard (ever seen a green floppy disk icon for the Save button?). In the Preferences dialog there’s a mixture of weirdly formatted option pages (see the top line jumping when scrolling up and down the Categories tree) and some antique Delphi-esque (or is that Borlandish?) buttons. Other dialogs, like Find and Replace, are crowded in the usual way and the buttons are all over the place.

EditPlus integrates itself in the Explorer context menu with its own entry, but this can easily be switched off from the Preferences window. It’s also possible to associate every file type know to EditPlus with the program, directly from the corresponding configuration panel. Nice.

EditPlus didn’t have any problems with my system’s ClearType settings and the Consolas font works nicely. It’s easy to switch the default font setting in EditPlus and there’s even a toolbar button with a popup menu that allows to switch the font quickly, from a customizable list of options.

The file selection dialogs used by EditPlus are the Windows standard ones, with a few extensions. They allow access to files from UNC paths and namespace extensions without problems. The so-called Directory selector, which is an alternative means to load files and browse the file system via a panel on the left hand side of the window, doesn’t offer the same level of compatibility, though. It does have support for Network Folders, but that’s cumbersome to use and it’s not possible to browse other arbitrary parts of the Windows Explorer namespace.

Syntax highlighting

Out of the box, EditPlus supported the following from my list of requested file types: C#, Perl, HTML and XML. The extremely large list of additional “user files” on the EditPlus web site had syntax highlighting definitions for Pascal/Delphi, but once again I wasn’t able to find any for diff/patch files or e-mail files.

Extending EditPlus with additional highlighters is easy, and there doesn’t seem to be a limit for this. Highlighters can be created in the form of text files and existing configurations can be extended with additional file types.

Extended file type detection mechanisms are not available in EditPlus.

EditPlus supports nine highlighting file types in its standard installation, while offering a few hundred, sometimes accompanied by auto-completion definitions, on the website. Once again, not the comprehensive package I was hoping for.

Extensibility

EditPlus offers a keystroke recording function that can listen to what the user types and repeat this sequence later. It’s possible to save the information to external files and by registering a keystroke recording file it’s possible to have a lot of these macros on the Tools menu. It’s possible to incorporate actions like Finding into the macro, as long as they are invoked via the keyboard.

“Intelligent” tool integration is supported, so tools can be started with a dynamically constructed parameter list, including information about the current file or the selected string. It’s also possible to capture tool output and parse it with a regular expression, which could be handy to call compilers directly from the editor. Nothing like this is included in the standard installation, though.

I couldn’t find any information about integration of external extensions in EditPlus.

Networking

EditPlus has FTP support, complete with an account manager and a comprehensive set of options. I was able to access a file via standard Windows XP WebDAV support, but FTP is the only thing integrated in EditPlus itself.

Support and community

The one support request I sent was answered quickly. There’s a Yahoo! Group as well as a Wiki, both of them apparently user supported. By the looks of the large user files download area, it seems that there’s an active user community, although it’s not as visible (like in large active forums) as with other products I have tested.

Price

A single user license of EditPlus costs US $30, which seems like a fair price for the tool.

Results in numbers

I have now started to make a tabular overview of the tested text editors available. You can find it here and I will keep it updated with new results as I continue to test.

The second test in this series, which is the best text editor for me, is about TextPad.

TextPad is a commercial product by Helios Software Solutions and is available from www.textpad.com. The version I tested was 4.7.3.

First impressions

TextPad is one of those programs that for some reason always hide behind their open online help windows. This is something I find extremely inconvenient and I’m happy that I have multiple monitors - it would be much worse otherwise.

The other thing I noticed is that TextPad also shows up its evaluation warning dialog from day 1. It might be just me, but I don’t like that… I’m one of those people that have every intention of paying for a product they like, but I want the chance to test it properly while being left alone with regard to nag screens.

General features

TextPad startup is very fast, due to the size of the editor. The application uses an MDI interface, selection of a currently open file is additionally possible from a list that’s shown in a docked window by default. It’s also possible to start multiple instances if needed.

Regular expressions are supported to the extent tested. TextPad goes fully for POSIX compliance, which means that \s doesn’t work for whitespace. Plus, POSIX compatibility has to be enabled first (in the preferences) to be able to use non-escaped braces, parentheses and pipe symbols. Anyhow, it was possible to search for ([^[:space:]]+) ([^[:space:]]+) and replace by \2 \1, so I’m quite satisfied.

Searching in multiple files is possible, but replacing is not available in a similar way.

The line wrapping button is right there in the standard toolbar. When line wrapping is on, TextPad tries to behave extremely well by indenting a wrapped line to the same degree as the start of the line - which leeds to the situation where it becomes difficult to see that one of the (visible) lines is actually a continuation of the other. With line numbers switched on things are a bit better, but I would really like it even better if the continued line wasn’t displayed with any indent at all.

It’s possible to configure the toolbars, but only to the degree of the prepared buttons. It seems to be by chance that the line wrapping button is provided - if I wanted to have a button to switch some other arbitrary option, chances are that wouldn’t be possible.

Scrolling and redrawing works nice and fast in TextPad. Although the editor visibly redraws a lot in situations like window resizing, it doesn’t interfere with work in any way. The scroll speed seems to be more or less independent from the degree of “coverage” of the editor pane. The only situation where scrolling suffered badly was when I loaded my 3.7 million chars on a line test file and switched on word wrap. Scrolling with the scroll bar was still quite reasonable, but navigating the cursor with the cursor keys was really sluggish. I wonder, don’t people who sell text editors test this kind of thing? I mean, I’m not inventing that… many machine generated XML files don’t have pretty indented layouts.

TextPad’s memory footprint is very reasonable. It started out at about 4MB and when opening files didn’t grow too much. File handling seems to be quite well optimised, as the editor bytes/file bytes ratio goes.

It’s a funny thing with hex editing in TextPad: it’s possible to open a file in “binary” mode, but the file seems to be inevitably opened in read-only mode. It’s possible to search for hex values, but replacing them is obviously also impossible. The online help doesn’t give any additional information on this. Another thing I noticed: by default, a file is opened in “Auto” mode (which is a selection in addition to “Text” and “Binary”), but this doesn’t seem to work very well. A lot of large test files I tried loading contained data that was certainly “garbage” if viewed in a text editor, but TextPad loaded them as text nevertheless, when left with the “Auto” setting.

TextPad can work with large files reasonably well, as long as they fit into free (physical, not swap!) memory. I loaded a file of around 656MB, which increased the application’s working set by 708MB (that’s nearly 8% overhead). Loading another large file failed because I didn’t have enough free physical RAM. Hint: the message in such a case is interesting, because it claims that “the disk is full” instead of telling the truth about the RAM situation.

It’s possible to use the keyboard to work with TextPad effectively. Keyboard configuration (Preferences dialog) enables one to configure arbitrary shortcuts for all menu entries as well as a lot of other commands and the insertion of special characters. Nice!

TextPad has a few simple text formatting functions. Although it doesn’t really understand formats like a bullet list, it’s able to reformat such paragraphs satisfactorily. This has to be invoked manually. More complicated formats like justified text are supported, but this breaks the bullet list, for example.

To define the file format for any given file, the user has to make the proper selection during file saving. It’s possible to save with DOS, Unix and Mac line endings and TextPad supports UTF-8, UTF-16 (which they call “Unicode”, don’t ask me why) and ANSI as character encodings. TextPad does support writing a BOM to UTF-8 and UTF-16 files, but this is an option for the so-called “document class” (see below, about highlighting), instead of being an option when saving. I haven’t found an option to switch the codepage or the locale for ASCII files.

I found all the TextPad settings in the registry at HKEY_CURRENT_USER\Software\Helios\TextPad 4, so it looks like it should be easy to transport them to another system.

System integration

TextPad’s integration into Windows is okay. The style of the application is a bit outdated, I think they guys at Helios should consider updating to a more current look and feel. But that’s not a problem of usability. The main dialogs are quite alright as well, although they could easily be a little bigger and/or resizable, which would make them less crowded. Some of the utility dialogs, like search/replace, suffer from a wide-spread problem: they are so tiny that the UI elements only just fit in, the buttons are already smaller than they should be with the text only just making it on the surface of the button (and that’s in English, one of the shortest languages there are) and all the buttons are crammed into some funny layout on the right side of the dialog. Nothing intuitive about that.

Integration into the Explorer context menu was done by the installer and seemed to work fine.

There were no technical problems using ClearType and the Consolas font with TextPad. Making the settings for the font proved a bit cumbersome, because the font is one of the settings that are made for each so-called document class in TextPad. There is a default document class, but that one is only used if no more specific class is found for a file extension, so to make the editor use the Consolas font in all configurations it’s necessary to make the change in many places instead of just one.

Virtual directories in namespace extensions as well as UNC paths are supported.

Syntax highlighting

It’s a funny thing with the standard highlighting support of TextPad: several highlighters aren’t configured in the standard installation although they are included. To explain: TextPad bases support file types on the so-called document classes, which are bound to a list of file extensions and aggregate all the settings specific to the file type. Out of the box, only four document classes (apart from some “internal” stuff like Binary) are configured: C/C++, HTML, Java and Text. The default installation includes 26 highlighting definition files, most of which are not in use. So, hint to the TextPad makers: save the user the work and create document classes for these by default!

The only one of my wanted highlightings configured out of the box was HTML. Using the existing highlighters, I was able to configure document classes for C#, Pascal and Perl. In the download area of the TextPad website I was able to find a highlighting definition for XML (you have to put such an external file into the samples folder to install it - huh?), but I was out of luck for diff and e-mail.

It looks to me as if TextPad supported an unlimited number of highlighters (i.e. document classes) and it’s easily possible to add extensions to existing classes. One thing is inconvenient, though: changes to a document class are never applied to open files, it’s necessary to close and reopen a file to see the effect of any chances to the corresponding class. It’s possible to create additional highlighters, they are stored in text format files.

TextPad doesn’t seem to implement any means of recognizing file types, apart from the file extensions.

Extensibility

TextPad contains a macro system, which works with an integrated recorder. It’s not possible to manually edit macros, they are stored in a binary format. The recording works quite well in its restricted way, I tested selecting text, typing and using search/replace. In multi-play mode, it’s possible to run a macro more than once without interrupting, thereby simulating a global loop.

It’s possible to integrate external applications into TextPad’s Tools menu and regular expressions can be used to parse the output of any such applications. This is useful to integrate compilers or make tools into the editor, to be able to jump directly to error locations. Apart from that, TextPad seems to have no other extensibility model.

Networking

There’s no networking support in TextPad.

Support and community

I had no reason to contact the Helios Software support. As support goes, they seem to be one of these companies who think that support can happen in a web forum… they do have a feedback form on their web page that customers are supposed to use (quote) “only if you have exhausted every other option, or have a purchase or licensing question”, and they also inform their customers that they may not reply to queries that have already been answered on their site. Well, personally I hate web forms and I almost hate web forums. What’s more, I looked at the forum and while there seems to be a nicely active community there, in many threads I didn’t see any reply that looked as if it actually came from somebody from Helios.

It might be just me, but that’s not what I expect support for a commercial program to be like. I really want an email contact so I can write down my requests in my own mailer and I can store the replies in my own archives, it’s as simple as that. A community forum and a web form with a disclaimer like the above are not good substitutes.

Price

A single TextPad license costs $30 (US) or £16.50 (UK), which sounds like an average shareware price to me. I guess the functionality is worth that.

Results in numbers

So here it is, the first test result in my quest for the best text editor. I started with UltraEdit because I had recently downloaded the trial version of it, and because the web site makes full-bodied promises about it: UltraEdit the #1 selling, most powerful, value priced text editor available! The ideal text, HEX, HTML, PHP, Java, Perl, Javascript, and programmer’s editor!

UltraEdit-32 is a commercial product by IDM Computer Solutions, Inc. and has its homepage at http://www.ultraedit.com. The version I tested was v11.10a (5/10/05) with a hotfix dated 07/07/05 installed.

First impression

The first impression I got was that the installer didn’t work correctly. The download I got was a zip file and I ran the setup from there directly, which apparently didn’t extract two additional files correctly. During installation, I also elected to install a German dictionary in addition to the standard English one, and the setup program wasn’t able to deal with that. A dialog told me that a file would have to be downloaded from somewhere, but this didn’t seem to work. After a while, the dialog switched to another file, and back again after another while. I recognized that one of the files was the standard English dictionary that was really in the zip file - I killed the setup process, extracted the two files alongside the setup executable, went without the German dictionary and finally the setup was able to complete its job.

General features

The program startup is fast enough. Although the evaluation period is a generous 45 days, a nag screen appears on program startup from day 1, which is not so nice because it hangs around in the way for a while. It’s actually possible to work with that dialog in the foreground, but I would have thought it should suffice to show that dialog when the evaluation period is nearing its end.

The document model is a mixture of MDI and a tabbed interface, the tabs are implemented in a docking window which can be closed. Anyhow, UltraEdit needs only to be started up once for any number of documents.

Regular expressions are supported, and the online help even lists a two variants, namely the “old UltraEdit syntax” and the “Unix-compatible” syntax. I was going for the Unix syntax and this proved to be a bit of a problem because I failed to see the sentence in the help file where it says that I have to switch UltraEdit to use that syntax in the Options dialog. After I finally found out about this I was able to search for the expression ([^\s]+) ([^\s]+) and replace by \2 \1, although I didn’t find in the help that there was any support for regular expression replacements at all. So, at a glance, very good!

UltraEdit’s memory consumption is a peculiar thing. Right after startup it was at only 4.3 MB, which went up to 7.5 after my first use of the file select dialog. Then, after playing around with the regular expression tests, with three small files open, I noticed that memory was now up to 23.6MB. I’ll keep an eye on this while I continue the tests. (Update: During the course of the tests, memory usage went up to about 30MB, but no more than that, even with a lot more files loaded and the editor running for two days.)

The button to toggle line-wrapping is right there in the default toolbar. Toolbar configuration is very flexible, although the user interface for it is not very intuitive. A nicer configuration dialog, like Office has had since 1997 at least, would do no harm here.

The next not-so-nice thing is scrolling and redrawing. Scrolling is sluggish - I have my keyboard set to the highest possible repeat rate, but I can’t scroll very fast by holding down the cursor key. I tried timing things, and I came to about 20 lines a second, merely 2/3 of the keyboard repeat rate. UltraEdit takes close to 100% CPU while the down key is being held. Even worse is redrawing: the complete editor surface is being redrawn all the time while the window is being resized, or while the splitter of the “File tree view” is being dragged (which also results in a resize of the editor pane). This redraw seems to be very slow, so that I can more or less watch it happening, regardless of the screen I’m running the editor window on. Both redrawing and scrolling get much worse when the editor pane is actually covered with text (long lines from top to bottom), resulting in bad flickering when scrolling up or down. Although it wasn’t reliably reproducible, I saw a scrolling bug a few times when using Page up or down, where only part of the editor pane would be redrawn after the key press.

In general, navigating large files can be quite painful. I have a test XML file with all its content (3.5MB) on one line and it’s not really possible to comfortably work in this file. The single line is wrapped at what looks like 4096 characters, for no apparent reason, but even moving the cursor left or right within any line is painfully slow, while up and down is even slower than in the test with the “normal” file.

Hex editing is supported, together with searching and replacing values. Regular expressions even work with hex edit search, but they are restricted to the ASCII text - would be nice if they also worked for the hex representation. Why not search for DEAD....?

UltraEdit is a disk-based editor which doesn’t load edited files into memory completely (there’s an option to use memory buffers instead, which I haven’t tested extensively). Editing extremely large files without performance issues becomes possible this way. To approach the programmers have chosen is to make use of temporary files - for every file that’s opened in UltraEdit, a temporary file is created first. There are a few options to control this behaviour, but only to a certain extent. For example it doesn’t seem to be possible to automatically have memory buffers used for files up to a certain size… but maybe that’s just a weird idea of mine, wanting to reduce hard disk traffic.

The editor is completely usable with mouse or keyboard. All menus and toolbars are configurable, as are the keyboard shortcuts. Very good!

There are a few simple text formatting options, but nothing too fancy. All formatting takes place after text entry and has to be invoked manually. It’s possible to define the layout of a paragraph (left, right, center, fill), but apart from that only indented paragraphs and line wraps at specific columns are supported.

UltraEdit supports all the various line endings as well as Unicode in UTF-8 and UTF-16, with and without BOM. All these types can be converted from one to the other. In addition, there’s ASCII to EBCDIC conversion. For non-Unicode files, the codepage and even the locale can be switched. Great!

UltraEdit can save its settings either in an INI file (stored in the proper path under Documents and Settings) or in the registry. In both cases, this should be transportable fairly easily.

System integration

UltraEdit does certainly look like a modern Windows application, but the UI could do with a workover in several places. For example, the Options dialog is enormously overloaded and the layout of many dialogs is inconsistent and unprofessional. Throughout the application, there are at least five different layout variants for standard buttons like Ok, Cancel or Help. Many dialogs should also simply be larger. Guys, read some UI guidelines! Once again I can’t help but wonder how a program goes through eleven (11!) major versions without anybody bothering about the UI. It’s the business card of an application, the first and most immediately impressive part of an application that a user sees. With UltraEdit, at least the main window doesn’t have any archaic elements, but the dialogs… oh well.

The installer integrated an entry for UltraEdit in the Explorer context menu, and file type registration and configuration is available directly from the Options dialog.

My use of ClearType was a problem at first, because fonts weren’t anti-aliased at all. I changed the font to Consolas and the result was even more horrible. An option in the long list on the General page helped: “Setting this may improve display issues with ClearType fonts on Windows XP”. Yes, that’s the name of the option. Fine that it works, but I can’t help but wonder if these guys really know what they are doing. What funny development language/environment are they using that allowed them to break ClearType support in the first place?

Handling files in virtual directories (namespace extensions) and UNC paths was no problem for UltraEdit.

Syntax highlighting

The syntax highlighting supports C#, Perl, HTML and XML (from my list of wanted formats) out of the box. Support for languages can be extended, but the means to do it are quite… hm… ridiculous, really. UltraEdit has a so-called wordlist, which is a text file in which a list of at most 20 blocks of highlighting configurations is stored. To extend the system, you have to edit that file manually and restart UltraEdit afterwards. The blocks in the file are numbered, and it’s up to the user to make sure that there are no duplicate numbers.

In a download area on the UltraEdit web server there’s a long list of add-on wordlist entries that need to be downloaded and manually fiddled into a wordlist file locally - as long as there aren’t twenty entries already in that list (11 are used by the default installation). I was able to find a Delphi highlighting there, but I didn’t find any for diff or e-mail formats.

Extensibility

UltraEdit can be automated by its macro system, which also supports a recording function. The macro editor didn’t look particularly comfortable to me, it could probably benefit from a UI workover as much as any other part of the application. For example, it would be extremely helpful if there was some hinting system that would show information about the syntax and parameters of the various commands.

The macro system itself looked quite capable and there are a few macros in the download area on the web site - together with the recording function that should be enough to get started.

Although the program comes with a few functional modules that look like they might be extensions (a colour selector, HTML tidy, …), I couldn’t find any information on an extensibility API. It’s possible to configure external tools to call from the editor, but these don’t integrate with the editor in any way.

Networking

UltraEdit is able to access files on FTP servers (my god, the UI!) and it was able to open a file from a WebDAV location that was previously configured in My Network Places. It didn’t have any support for WebDAV of its own, though.

Support and community

There’s an active community forum for UltraEdit and a support e-mail address at support@idmcomp.com. I haven’t had reason to contact the support team, but I generally like the fact that they want to hear about bugs and feature requests in this direct way, because I haven’t had many good experiences with companies who supposedly handle their support solely via forums (apart from the fact that forums are far more difficult to use for me than my own mailer, you usually have to register first (yeah, yet another password!) and so on… but I digress).

Price

The price for a single, non-concurrent, user license is $39.95 at the current time, which seems a little on the high side, as shareware prices go. It’s nevertheless a reasonable price to ask, given the largely mature functionality that UltraEdit offers.

Other miscellaneous impressions

Why the *#**! can’t I resize the Options dialog? The options list on the General page is long and even too wide to fit without scrolling, yet I can’t resize the dialog.

Results in numbers

As announced, I assign points for each of my categories, from 1 (worst) to 100 (best). As this is the first in a sequence of tests, I won’t assign extremely high nor extremely low numbers right now, apart from places where the asked functionality is simply absent. So the real range is 20 to 80 for this first test.

I guess every computer user in the world has (been) asked that question at least once, and many have invested a lot of time in the quest for the best, if not the perfect, text editor. Apparently many aspects of the problem are a matter of taste, and the fact that the technical environments are changing all the time (and even faster for us programmers than for most other people) doesn’t make it any easier.

I have once again decided that I should have another look at what’s available and I thought it might be a good idea to publish my findings in a way that allows others to benefit from them. I don’t plan to look at all available text editors out there at the same time, but rather to take the time every now and then to look at one or a few and document my findings in a categorised way.

Below I’ll publish the criteria by which I will rate the various contenders. While I was trying to set up that list, I already recognized one problem: I won’t be able to do it at this time. I’m sure there are editors out there that will surprise me with features I didn’t think of at this time, and I might recognize these features as important as time goes on. So I’ll probably re-evaluate the criteria every now and then.

Finally, I should note that I’m looking at editors running on Windows, this being my current platform of choice for my desktop systems.

The criteria

Let me say this up front: this is not supposed to be an impartial evaluation. These criteria are my own, not someone else’s. You might have different priorities, and while I’d like to hear about them (feel free to comment), I probably won’t respect them in my evaluations.

All distinct criteria will be rated on a scale from 1 to 100. I always find it funny when people say: “I’m using a scale from 1 to 10 and the rating for this item is 7.5.” That’s why I’m going for 1 to 100.

Feedback, please!

If you know of an editor, or you have created an editor that you give away, for money or for free, please contact me and tell me about it! I’d really like my list to be comprehensive. I’d like to set a limit though, feature-wise: your editor should have something interesting that standard Windows Notepad doesn’t have, to be considered for inclusion. It doesn’t matter if your editor fulfills all the criteria above - I’ll include editors that don’t suit my own needs, as they may suit others’.

New articles will be published on my blog, in the Best text editor category.

Apparently, I’m the only guy out there who doesn’t know this, but I found myself wondering where the much-quoted user config file profile.msh could be found in my installation of the Monad beta. The only information I was able to find after quite a while was that it should have been in {systemdrive}\Documents and Settings\{username}, but it wasn’t there. I’m sure this is really documented in some place I couldn’t find, but I eventually used Filemon to find the location where msh.exe is looking: {my documents}\msh\profile.msh. Ha! I also found that another location is also looked at (first, actually), namely {all users documents}\msh\profile.msh.

So now I’ve published this here, I won’t have to find it out again next time, and maybe someone else can benefit from it as well.

I’m using Developer Express XtraBars in my .NET applications. With one of the latest releases, XtraBars also support the new skinning technology, which the website depicts quite inadequately but which takes the experience of an application based completely on DX controls to a new level visually.

Now who would have thought that a package such as this would have grave deficiencies in other areas? Well, custom drawing is one such area. Recently I wanted to create a simple bar item that would be able to specify its own background and foreground colours, independent of the configured paint style/skinning. I played with deriving my own BarItem, BarItemLink, BarLinkViewInfo, PrimitivesPainter, PaintStyle and several other classes for the larger part of a day, until I finally decided that the current structure of the whole XtraBars painting is such that this simple modification is enormously complicated, IF I want to stay within the extensibility structure that’s available out of the box.

After spending a lot of time with these efforts, I had quite a good understanding of how the painting really works, and I went on to extend XtraBars with a simple event on the BarItem that lets me do custom drawing in an event handler. If you want to use these changes, you can download (or look at) a standard patch file here, but there are a few things to consider:

1. I use VS 2005 and .NET 2, therefore the patch uses the generic EventHandler<T> delegate. You’ll have to replace that with a non-generic delegate if you want to use this for VS 2003.
2. You’ll only be able to use this if you compile your XtraBars source code yourself.

If these points are no problems to you, you’ll be able to use code like this in an event handler to draw a bar item link yourself:

private void barButtonItem1_DrawLink(object sender, DrawLinkEventArgs e) {
  BarLinkState st = e.BarLinkPaintArgs.LinkInfo.CalcRealPaintState( );
  if (st == BarLinkState.Normal) {
    e.BarLinkPaintArgs.Graphics.FillRectangle(
      e.BarLinkPaintArgs.Cache.GetSolidBrush(Color.Yellow),
      e.BarLinkPaintArgs.LinkInfo.Bounds);
    e.BarLinkPainter.PPainter.DrawLinkCaption(e.BarLinkPaintArgs,
      e.BarLinkPaintArgs.Cache.GetSolidBrush(Color.Red),
      BarLinkState.Normal);
    e.Handled = true;
  }
}

This code would result in an appearance similar to this, regardless of the paint style used:

Obviously I sent this patch to support together with my wish for a similar feature in the box, and I got the reply that custom drawing was an item in their list of things to do. Not a completely new piece of information… anyway, if you want to use it now, consider going a similar way as I did.