Marks are something that my text editor will have under the hood; they are not a feature that would be directly visible to the user. Specifically, a mark is a chunk of data that is associated with a span of text (typically a single word or phrase) within a file being edited. Marks are not saved with the text as part of the file, but the file, while open, could have thousands of marks associated with various parts of the text. Each mark remains associated with its span even as the text is being edited. Marks would be useful for implementing syntax highlighting, bookmarks, and other features that a modern text editor would be expected to offer.

Each mark belongs to a track, which is conceived as being of the same length as the main text. Each point on a track corresponds to a character position within the main text. Each mark takes up certain points on its track, so each mark corresponds to the characters at the corresponding positions — the mark’s span. Each point on a track is occupied by no more than one mark, so marks on the same track cannot overlap. Thus, if a span of text is to have two marks, the second mark has to belong to a separate track. The editor can generate as many of these separate tracks as needed.

Here is an example involving three tracks of marks:

Track 1: art noun adverb_ verb_ noun art adjective noun
Track 2: U                      U                      PB
Track 3:    O    O       O     O    O   O         O     M
Text:    The girl quickly found Fido the yellowish mutt.<

(Note that the less-than sign at the end of the text represents a newline character.)

Take a look at each track in this example:

• Track 1 marks each word, each contiguous sequence of letters, with its part of speech: article, noun, verb, adjective, or adverb. Each mark in this track takes up the length of its corresponding word.
• Track 2 assigns a class to each character other than a space or a lowercase letter — “U” marks each uppercase letter, “P” marks each punctuation character, and “B” marks the mandatory-break character at the end. In this case, each mark takes up no more than one character.
• Finally, Track 3 marks the characters where the line can be broken on a wordwrapped display: “O” marks optional-break characters like spaces, while “M” marks mandatory-break characters like newlines. Again, each mark corresponds to a single character.

Note that each mark has a name. This name in effect assigns a class or category to the mark’s span. Track 1 marks some words as nouns and others as articles; Track 2 marks some characters as uppercase letters; Track 3 marks each space as an optional-break character to make wordwrap easier to implement. Mark names allow the text editor to treat different spans in the same way if they have the same mark name, but differently if their mark names are different.

(Another way of thinking about this, if you’re familiar with object-oriented programming, is that a track corresponds to an object property (part of speech, character type, line-break type), and a mark corresponds to a value assigned to that property.)

You can see how this would be useful in the bowels of a text editor. Marks would be useful not only for marking the locations of line-break opportunities or of different types of characters; they would also be useful in syntax highlighting (marking the locations of various classes of words or phrases) and for spellchecking-as-you-type.

Marks would likely be most useful for marking up just the text that is about to be displayed on the screen — finding where each line of text can be wrapped, determining the “classes” of words so that the editor knows what font and style to use when drawing the text, finding misspellings, and so on. Marking up the rest of the file would be a time-consuming chore that would generate a lot of data that would then have to be stored somewhere in case it is needed later, so this kind of busywork is best avoided.

Implementation

The text buffer contains nothing but text from the open file. Loading and saving files is simpler if the buffer contains only the text loaded from or saved to files. Search and replace is also simpler if the buffer contains all of the data, and only the data, to be searched. (Syntax highlighting relies on searches in the background, so searches need to be fast, and they are faster when they are simpler.) So marks and tracks are stored elsewhere.

Marks never overlap within a track, so a track could be represented as an array of short records, where each record contains just a mark name (as String) and a span length (as Integer). If the mark name is blank, then the span is just unmarked text. So the data for Track 1 above would look like this:

Name       Length     | (Corresponding
as String  as Integer |  span)
---------  ---------- | ---------------
article        3      | "The"
               1      | " "
noun           4      | "girl"
               1      | " "
adverb         7      | "quickly"
               1      | " "
verb           5      | "found"
               1      | " "
noun           4      | "Fido"
               1      | " "
article        3      | "the"
               1      | " "
adjective      9      | "yellowish"
               1      | " "
noun           4      | "mutt"
               2      | "." + EndOfLine

I’m storing lengths, not offsets, to make it easier to keep marks and spans together when text is inserted or deleted. If text is typed in the middle of a span, then all that needs to happen is to increment the length of the span within the mark’s record. If I need to find the mark that corresponds to a specific offset within the text, I just keep adding span lengths until the sum reaches the offset.

I’ll have more to say about this later. I’ll need to spell out exactly how this information is laid out in memory. I’ll also have to figure out how I want this information saved into temp files and then reloaded when the mark information is needed. But that’s for later. Right now I just wanted to get something posted.

String objects

Strings in REALbasic are immutable — that is, you can’t write code to just reach inside a String and rearrange its contents. If you write code to change the text in a String, your program will always create a new String object and copy all of the text from the old String into the new String. That’s just how REALbasic Strings work. The whole point of a text editor is to allow you to change the text in a file at any time, so this operation should be efficient, and REALbasic’s String class is not efficient for this.

This is how you insert a new piece of text into a String:

Dim offset as Integer
//...
buffer = Left( buffer, offset ) _
    + newText _
    + Right( buffer, Len( buffer ) - offset )

Here is what happens under the hood whenever the above code is run: REALbasic creates a new “buffer” object, copies all of the data from the old “buffer” and “newText” objects into the new “buffer” object, returns the new “buffer” object, and marks the old “buffer” object as empty space to be reclaimed by the operating system. This isn’t so bad if “buffer” is always a small String, but what if the String is the text from a 200KB file? Then every time the user types something, the editor has to borrow a 200KB block from the operating system to build the new object, then copy 200KB of data from the existing buffer into the new object, then let the REALbasic framework “collect” the old buffer so the OS can have its 200KB block back. This takes up both CPU time and memory. Surely there is a way to insert new text that takes up less?

There is, of course. Instead of keeping a file’s contents in memory as a single big long String, the editor could split the file’s contents up into many short Strings and store references to those Strings in an array. Inserting a String into an array actually inserts only the location of the String, not its contents, so insertion is quick. Now the code to insert new text into the buffer looks like this:

Dim index, offset as Integer
Dim leftPart, rightPart as String
//...
leftPart = Left( buffer( index ), offset )
rightPart = Right( buffer( index ), _
    Len(buffer( index )) - offset)
buffer.Insert index, leftPart
buffer.Insert index+1, newText
buffer.Insert index+2, rightPart

The code is longer, but it runs faster because there is less going on under the hood: New text is inserted by splitting only a single segment of the file and inserting the new text in between the parts. It isn’t necessary to append the parts together into a long String again, because the array keeps the parts in order.

This clearly alleviates the problem, but it does not solve it: To insert new data into the buffer, you still have to create a copy of data you already have.

In addition, there is another problem: Searching the buffer becomes very awkward when the buffer consists of lots of fragments in an array instead of one great big long string. So in this case the editor would probably append all of these items into a single string when a search is about to be performed. Again, the data in the many segments of the buffer would need to be copied into a separate String object just to perform a search. As before, this takes time that the editor could spend more productively doing something else, and it doubles the editor’s memory requirements because it has to make a second copy of all of the text data. There has to be a better way.

(Side note: Theodore H. Smith offers a REALbasic plugin called ElfData. The plugin offers special string classes (ElfData and FastString) that let you split and recombine strings much more efficiently than REALbasic’s String class, mostly by cutting down on the amount of data copying and memory allocation that has to be done at runtime. However, the problem (from my perspective) is the same: The ElfData and FastString classes still work like String objects. To insert text into a long string, you still have to break the long string apart and copy all of the text from the various pieces into a new object, and you need space in memory for two copies of your data to do that. A text editor would use memory more efficiently if it could avoid creating a second copy of the text altogether.)

MemoryBlock objects

Unlike String objects, MemoryBlocks in REALbasic can be updated in place: You can insert new text into a MemoryBlock without the REALbasic framework recreating the whole MemoryBlock each time. Further, as Charles Yeomans points out, if you use a BinaryStream object as the front end for a MemoryBlock, you end up with a buffer that acts like a file: you can “seek” to a given position anywhere within the buffer and read or write data at that point, and if you write data beyond the end of the buffer, then the buffer will be made large enough to hold the new data.

When you write ten bytes of data into the MemoryBlock, then ten bytes of space within the MemoryBlock, beginning with the current position, will be overwritten. If the current position is ten or more bytes from the end of the buffer, then no data in the MemoryBlock is copied or moved, so the write operation is extremely fast. However, if the current position is less than ten bytes from the end of the buffer, then a new MemoryBlock has to be allocated, and the data in the old MemoryBlock has to be copied into the new one. If you use a BinaryStream object as the front end for a MemoryBlock, as explained in Charles Yeomans’s article, the new MemoryBlock will be twice the size of the old one, so the need to move data to a new MemoryBlock should not arise often.

But if you want to insert text into a MemoryBlock, you don’t want to overwrite the text already in there. So it would seem that you’d still need to copy existing text to a new location to make room for the new text. However, if the text to be overwritten is actually considered garbage and not part of the text you want to keep, then you can “insert” your text extremely quickly. This is the basis for the gap buffer that is used in many text editors. A gap buffer is a text buffer with three regions: the text before the current position, the text after the current position, and the “gap” in between. The gap is of course just a stretch of nonsense text that isn’t considered part of the main text and that is present to be overwritten with whatever new text the user types or pastes in.

If you need to search the text being edited, the search might be easier if the gap is removed. This of course requires copying text within the buffer to remove the gap. However, no new objects are created, so the editor would not need to borrow more memory from the operating system to perform this operation.

MemoryBlocks are best

Clearly, if you want to write a text editor in REALbasic, it is better to use a MemoryBlock to store the text being edited. Inserting and deleting text will be much faster and will require less memory than if you were to try to store the text in String objects.

This is just a quick overview. I’ll flesh out the ideas here in later posts.

My text editor is going to need a buffer system. I need a buffer for at least two things:

• My custom text control will need a buffer to cache the text being displayed in the editor window, so that it can redraw the text when the window has to be redrawn. The buffer also needs to hold font and style information, so the control knows what fonts to use to redraw the text. (I’ll need this so that I can implement syntax highlighting.)
• The editor itself needs a buffer to hold the text of the file being edited.

I’ve thought this over. What I want is a buffer that offers the following:

General buffer functionality

Ideally the text buffer should be useful outside the context of a text-editor application. The user should be able to insert or delete text anywhere within the buffer, search the buffer for phrases or regular expressions, and extract substrings. I’m thinking of giving the buffer the same functions available for strings in REALbasic — the “+” operator to append data to the end of the buffer, “Mid” and other functions to extract substrings, “InStr” to find substrings, and so on. Some other functions that a text editor needs might also be useful in a general-purpose buffer, such as counting the number of words or lines.

Sections

I want an application that can treat a single long file as many sections of text. The characters that determine where one section ends and the next begins should be selected by the user. For example, you might use a line of hyphens to separate one section from the next, so all of the lines between two lines of hyphens would constitute a single section.

The significance of sections is that they would be like records in a database: You can get a subset of the complete file by specifying a phrase or a regular expression that each section must contain if it is to be part of the subset. The subset would contain only complete sections, not just the individual lines containing the search matches. You could then decide what to do with the sections in the subset — print them, sort them, export them to a script or a command-line program, or whatever.

In essence, if you were to take advantage of sections, you could use a text file as a simple database of notes or code snippets, a journal, or a card file.

Marks

A text editor often needs to mark spans (substrings) of text within the complete document. A span within a source-code file might be a keyword or a comment and thus should be displayed in a style distinct from the style used for the rest of the text. A span might be a bit of text that the user wants to return to later, so that it needs to be marked internally with a bookmark. In each case, this extra information associated with a span of text needs to remain attached to the span while the user is editing the document. In fact, even if the editing affects the span text itself, then the information needs to remain associated with whatever part of the span is left in the document.

This extra information is called a “mark.” Marks would be useful for associating style information with spans, for marking the results of previously run searches, for storing bookmarks within the text, and for other things.

Marks would be stored separately from the text in the buffer. The text in the buffer is not mixed with any other kind of information, so that searches through the text don’t require any kind of preparation beforehand and in fact can be performed at almost any time. (I strongly suspect that my text editor will need to do a lot of searches in the background, particularly if I want such things as syntax highlighting, line and word counts, and so on, so I want searches to be as fast as possible.)

Recording

The buffer should record each change that is made to the text in the buffer. Both text insertions and text deletions should be recorded, along with the locations where each insertion and each deletion occurred.

This facility would provide the foundation for several features desirable in a text editor, most notably undo/redo, review of changes made to a file, and macros.

Autosave

I want the buffer to save changes automatically, but without overwriting the original file. So the buffer needs two “stores” or places to load and save text — the original file or text source, and a temporary one for holding changed text until the user decides whether to discard the changes or to save them as a new file and overwrite the original.

If the “temp store” is somewhere other than memory, such as a folder on your hard disk or thumb drive, then you have some insurance against losing your changes in the event of a system crash or a power outage. Because the changes are kept separate from the original file, you still have the option, after a crash, to either commit the changes to the original file or to discard them.

This storage would be handled by two objects other than the buffer itself. The buffer wouldn’t know and wouldn’t care how these two objects load and save data. So although the original store would usually be a file on a hard disk, and although the temp store would usually be a folder, either store (or both) could access data on a website or an FTP site. On the other hand, if an application only needs the buffer for a few seconds, either store (or both) might access data in data structures in memory and never read or write anything on disk. This will help make the buffer system more useful in more situations than just as part of a text-editor application.

Segments

I want the buffer to be able to load and edit files too large to load completely into memory without bogging down the computer. Of course, the only way to do that is to treat such a file as an array of smaller chunks or “segments” and then load only the segments that the user is reading or editing.

Note that segments are not sections:

• Segments are intended to be of roughly similar size, though segments will grow and shrink as the user edits them. If a segment grows too large, the software will split it in two; if it gets too small, it is merged with a neighboring segment. Segments exist to simplify the processing that the software has to do when working with very large files or strings.
• Sections can be of any size useful to the user, and it is the user who determines where a section begins and ends.

Segments would also simplify some of the other work that a text editor would need to do, such as updating the location of tag spans. Since tags themselves are stored outside the text, my buffer code would need to do some extra work after each edit to ensure that each tag remains attached to its span. If each tag stored its span’s location as a single integer, as an offset in bytes from the start of the file, then this would make editing very large files problematic, because then every tag in the whole huge file might be affected. If instead a span’s location is an offset from the start of a segment, then a change in the text affects only the tags whose spans begin within that one segment. So segments will be very useful in making the job of editing huge files manageable.

Summary

So these are the basic features I want: sections, marks, automatic storage of changes, and the ability to tackle huge files. A buffer class with a feature set like this should be useful for building a fairly sophisticated text editor. I’ll flesh out each of these features in future posts.

I have several reasons:

• Handling of large amounts of text. The TextArea is reportedly very slow when it has a huge amount of text in it. Although most text files my editor will handle will likely be under a megabyte in size, I’d like the editor to be able to work with huge files, tens or hundreds of megabytes in size, every once in a while.
• Memory use. The complete file has to be loaded into the TextArea. There is no provision to defer loading a part of the file until the user actually scrolls or jumps to that part. This is necessary if the control is to support the editing of huge files.
• Word wrap. The TextArea doesn’t let you turn off word wrap; a text editor should let you do this (the better to see the structure of source code with very long lines).
• Indentation. You can indent the first line of a paragraph in a TextArea by inserting tab characters at the start of the first line in the paragraph, but the TextArea doesn’t provide anything else for indentation. Whenever a paragraph is wrapped, each line after the first one always starts at the left edge of the control; a text editor ought to be able to indent all of the lines in each paragraph. The structure of a text outline, for example, is easier to see if every line in each paragraph, and not just the first line in each, is indented.
• Tabstops. The TextArea supports only the conventional fixed-width tabstops. These tab stops are useful for indenting the first line of a paragraph but aren’t much use in arranging substrings of text separated by tabs. Variable-width tabstops are a feature of word processors, not text editors, and they usually have to be set by the user — but I’d like to have my editor support elastic tabstops, which the editor can just calculate on the fly, and which the user doesn’t even need to set.
• Showing invisible characters. Text editors often have an option to display normally invisible characters using visible substitutes — spaces as raised dots (“·”, U+00B7, middle dot), or tab characters as right-pointing triangles (“▶”, U+25B6, black right-pointing triangle), or newlines as pilcrow signs (“¶”, U+00B6) or as left-pointing arrows (“↵”, U+21B5, downwards arrow with corner leftwards). TextArea doesn’t offer anything like this.
• Background colors. It would be nice if my text editor can use different background colors to mark spans of text that match ad-hoc searches. TextArea can show text in different colors, but it has one background color for selected text and one for unselected text. This isn’t a huge deal, but I’d like a little more flexibility. I’d like to use light or pastel background colors for search matches and a dark color for the actual selection.
• Drawing events. The TextArea does not offer any events that would allow a subclass to draw onto the canvas or to alter the positions of text on the canvas. Therefore I can’t create the kind of control I want by subclassing TextArea.
• Hiding lines. Code folding and outlining are two text-editor features that would require the control to display two lines while hiding the lines in between. The TextArea does not offer this, either.

It is wonderful that REALbasic lets you roll your own controls in REALbasic. But others have already written substitutes for the TextArea — True North Software’s FormattedText control and Alex Restrepo’s CustomTextField are examples. Why not use one of them? Because they don’t offer the feature mix I want, and because I like the idea of having my own code that I can modify as I see fit and having the freedom to add the things I want.

So I’ll be spending time figuring out how to wrap lines of text on a Canvas control, how to display a blinking cursor, how to display text as selected as the user drags the mouse over the control, how the text should be structured in memory to support all of these features, and how to regression-test everything so I know it all works. Hopefully the results will be worth the effort.

I like REALbasic. The language is easy to learn, easy to write, and easy to read. The REALbasic IDE provides lots of pre-built controls for building your program’s user interface, but you can also create your own controls from the ground up. If you have the Professional version of REALbasic, you can write your program once and use it to build executables for Windows, Mac OS X, and Linux all at once. And if some part of your program should prove to be unacceptably slow, you have the option of writing a REALbasic plugin in C++ to speed things up.

What’s good about REALbasic?

There is a lot to like about this language.

• The language is easy to pick up. It’s BASIC, after all.
• The language is object-oriented. You can create your own classes, or subclasses of existing classes. You can define interfaces as in Java and then create classes that implement those interfaces.
• Objects are reference-counted and are deallocated automatically when no other object points to them.
• Some of the features the language has include:
  • Basic data types: Integer, Single, Double, Boolean, Color, Date, Currency, String, Array, Variant, Dictionary (actually a hash table), MemoryBlock. REALbasic has many functions for dealing with variables of each type.
  • Low-level data types for working with binary files or C functions in a library or the operating system: Int8, Int16, Int32, Int64; UInt8 (Byte), UInt16, UInt32, UInt64; Ptr; CString, PString, WString.
  • Literal syntax not only for hexadecimal (&hFF), binary (&b11101101), and octal (&o137) numbers, but also for colors (&cFF6F00 for orange) and Unicode codepoints (&u2014 for an em dash).
  • Delegates are essentially typesafe function pointers. A Delegate can point at any function (or object method) with a specific list of argument types and a specific return type — for example, any function with a first argument “As Integer”, a second argument “As String”, and no other arguments, and that returns a Boolean. You can use these at runtime and change what your program does in response to a keystroke or a button press.
  • Support for exceptions. You can define your own exception classes, use the Raise statement to throw an exception, and Try…Catch…Finally to catch and handle exceptions.
  • Declare lets you call subroutines or functions in DLLs (on Windows) or shared libraries (on Mac OS X or Linux).
  • Assigns lets you set up a Sub to be called with “theSub(a, b) = c” instead of “theSub(a, b, c)”.
  • Extends lets you set up a Sub or Function to be called with “a.theSub(b, c)” instead of theSub(a, b, c)”.
  • #If…#Endif allows conditional compilation. This is most useful for allowing or “commenting out” code depending on whether (1) a constant is defined, or (2) the running within the IDE, or (3) the application is running on Windows or the Mac or Linux.
• The IDE lets you build your GUI by dragging controls onto a window and setting their properties, just as Visual Basic does.
• If the controls supplied with REALbasic don’t do what you want, you can subclass an existing control and write event handlers to change how it works, or you can even subclass the Canvas control and create your own custom control from the ground up.
• REALbasic comes with classes for all sorts of things — standard dialog boxes (for picking folders, files, or colors), regular expressions, XML, databases, shell commands, graphics (lines, shapes, text), networking (including sending data to and receiving data from websites), conversion between text encodings, cooperative (not pre-emptive) threads, sound, editing video (via QuickTime), etc.
• There is even a command to make the computer speak the text you pass to it. (This works on Windows and on the Mac, but not on Linux.)
• RBscript is a scaled-down version of REALbasic that you can compile into your application so that users can run scripts. Even better, these scripts are compiled, not interpreted, before being run.
• REALbasic (the Professional edition of it at any rate) is cross-platform — you can build applications for Windows, for Mac OS X, and for Linux from a single project file.
• REALbasic code is compiled into native machine code, not interpreted.
• You don’t have to pay any royalties for distributing your applications.
• REALbasic Personal Edition for Linux is free. If you have a Linux machine, you can write and test REALbasic code on it and not pay a cent to REAL Software until you’re ready to build executables for Windows or the Mac.
• If the code that REALbasic produces isn’t fast enough, you can write a plugin for REALbasic in C++ containing code to alter the contents of your REALbasic objects.
• Many developers have developed their own plugins and controls and offer them either for sale or free of charge.

What’s bad about REALbasic?

There are some drawbacks to REALbasic, though none of these are showstoppers for me personally.

• Every version of REALbasic other than the Personal Edition for Linux is commercial software. If you want to compile for any platform other than Linux, you have to pay up.
• REALbasic’s IDE can be constraining at times. You can only see one function or one class method in the IDE at a time. People accustomed to seeing two or more function definitions at once in a text editor may chafe at this.
• REALbasic’s controls reflect the lowest common denominator of the equivalent controls on the three platforms. For example, REALbasic offers a TextArea for letting the user edit styled text, but the TextArea does not have built-in undo; you have to supply that.
• REALbasic’s executables are large. A do-nothing GUI application is around 1.5MB because REALbasic compiles a large part of the runtime framework into the application. Even a do-nothing console application is about a megabyte in size.
• REALbasic does not support Cocoa (although a new release that does support Cocoa is supposed to be released by the end of the year), so any Mac OS X application built with REALbasic right now relies on Carbon. (This is one reason why developers who develop only for the Mac often prefer Objective-C and Xcode over REALbasic.)
• REALbasic currently produces only 32-bit code, not 64-bit code.
• Documentation for the plugin API is spotty, and actually writing the plugin appears to be something of a dark art. (I might try gathering this information and writing up a how-to on building a plugin with gcc in a later post.)
• REAL Software sometimes adds new features to REALbasic and releases them before they are ready. (The latest release, 2009R4, has new report-building functionality that is apparently not yet ready for prime time.)

Good enough

Every programming language and package involves tradeoffs. REALbasic, like every other programming language, has its good points and its bad points. I like its good points and I can live with its bad points, so I’m going with REALbasic.

Links

• Markus Winter gives his take on REALbasic.
• Thomas Tempelmann warns those new to REALbasic about some annoyances to watch for.
• Many developers who develop only for the Mac prefer Cocoa and XCode over REALbasic.

What I want the editor for

I like to keep notes and outlines on things.

I would prefer to keep my notes and outlines as plain text if I can. Plain text is an open format and the most massively well-supported data format on Earth. There are dozens if not hundreds of text editors in existence for virtually every operating system on the planet, so if you should for whatever reason lose the ability to use your favorite text editor, there’s always another one available.

But why write yet another text editor?

For one thing, I’m not 100% satisfied with most of the text editors I’ve tried so far, which are generally geared toward programmers. (I want to do coding, of course, but I also want to do other things with the editor.) For another thing, I have some ideas for features I’d like to see in a text editor. For another thing still, I’d like to have a text editor that works not just on one OS, but on all three of the major platforms — Windows, Mac OS X, and Linux. Finally, I just want to see if I can do this.

This is a list of some features I’d like to have:

• I want the ability to keep many individual notes, and I want to be able to see only the notes that match certain criteria. I want to keep all of the notes in one place — a single text file. So I want a text editor that can tell (or be told) where one note ends and the next begins.
• I also want the editor to make manipulating notes as simple as manipulating files with a file manager. (Perhaps the editor would have a display mode where notes are displayed as icons. I’ll have to think more on this.)
• I want the editor to support Unicode. Although 99.9% of my text would be plain ASCII, occasionally I’ll want to use letters with diacritics, or special symbols, or even an occasional IPA or Greek or Japanese character.
• I want the editor to save changes automatically, without altering the original file. When a file is first opened, the editor should create a working folder for the file and copy the file’s contents into the folder. (This copying should be done in a thread so that the user doesn’t have to wait for the process to finish before he can start editing.) Any changes made to the file should be saved automatically to the copy in the working folder; the original file is left untouched until the user specifies that the original should be overwritten with the working version. This also ensures that changes made will survive even if the system crashes and must be rebooted.
• I want the editor to save a history of changes into the working folder, so that changes can be undone, redone, and reviewed even after the system is rebooted.
• I want the editor to handle huge files gracefully. If the file to be edited is too big to load into memory, then the editor should copy the file’s contents into multiple smaller files, each small enough to load. This means that the editor would be able to handle files of any size (as long as the disk has enough space for a copy of the original file).
• I want the editor to make it simple and easy to create and reuse regular expressions for searches and filters. You should be able to use regular expressions like Lego blocks and piece them together to create more complex regular expressions, then give a name to the result and save it so you can use it later.
• The editor should support incremental search, so that the editor jumps to the next match for a phrase as you type in the phrase.
• I want the editor to use stylesheets. A stylesheet in this case consists of a series of rules. Each rule spells out some text to look for and the font, style, and color to use to display the text. (The font need not be monospace; you should be able to use whatever font suits you.) The text to find might be a direct match for a regular expression, or it might be whatever text lies between matches for a pair of regular expressions.
• Stylesheets should also support rules for automatic indentation, such as what indentation to apply if the current line begins with a specific character, or what indentation to apply to the new line after the user hits Enter.
• I want the editor to support different stylesheets for different sections within the same text.
• I want the editor to support elastic tabstops so that “fields” within adjacent lines are lined up in the display, so I can create “tables” on the fly.
• I want it to be easy to record, play back, write, edit, and debug macros from within the editor. I’m considering devising my own macro language for this.
• I want to be able to enter commands just by typing, or by highlighting some text in the file and pressing a key. These commands could be built into the editor, or they could be macros or external scripts.
• And of course I’ll want most of the other things that are expected in a text editor: line numbers, the ability to filter text through an external script, conversion of text from one encoding to another, easy insertion of text clips, autocomplete, and so on.

I’m sure I’ll come up with other ideas, but this is the basic feature set I want.

What I’ll probably do is try to make each post (after this one) an essay, something longer than just a few sentences, something with some meat in it, instead of just running to the “Edit Post” page every time I learn something new. This would probably also make reading my stuff a little more interesting.