HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences

With 1,770 text editors and counting it's clear TheIdealEditor has yet to be created. Many of those editors though miss something essential that this one will have: a community and knowledge source of a couple thousand editors before it.

The whole idea behind this is to take what we know about TextEditors, analyse the CommonGripes of current TextEditors, and create something that will truly work for everyone.

Here are some questions that I think should be answered:

And some odd ones to get the ball rolling:

and so on.

I look forward to your ideas. --lf

That said, you might look at the link for another take on editor classification. Dr. Bezroukov classifies Editors as Eastern Orthodox or Western Orthodox. Eastern Orthodox editors are characterized by a command line, text folding, and a script language. Western Orthodox editors are characterized by support for regular expressions and piping through external filters.

In that classification, the canonical Eastern Orthodox editor might be IBM Xedit, and the canonical Western Orthodox editor would be Unix vi.

Lots of hybrids exist. Editors based on the Scintilla edit control get code folding and syntax highlighting as part of what Scintilla does, but may have a script language like Lua embedded as well.

Some editors, like Gnu Emacs, are written in a script language. Gnu Emacs is an interpreter for a dialect of Lisp, and most of the editor is written in the dialect of Lisp it implements. (The exceptions could have been, but weren't for efficiency. And we are seeing cross platform editors written in languages like Java and Python, which can run anywhere those languages have recent runtimes involved.

While it will be fun to discuss, I don't think we'll ever see an ultimate universal editor. First you have to define what you mean by the term "editor", then you have to specify what you expect to do in it.

Whatever you come up with, you'll encounter problems, starting with "universal". Consider the TextEditors Family that runs on calculators. The platform will severely limit what you can do.


While it will be fun to discuss, I don't think we'll ever see an ultimate universal editor. First you have to define what you mean by the term "editor", then you have to specify what you expect to do in it. --DMcCunney

Well considering text is represented in binary, it should be possible to edit as low as the bit level. With this characteristic it really should be a "universal" editor in the sense of computer files.

So the editor can patch binaries as well as write/edit text? There are already binary editors (and a few are listed here.) How often do you actually need to do that? (I think I can count on the fingers of one hand the times I've done it, and that's over several decades.

Is code folding really something that users use a lot? Is it designed because of bad programming? It is necessary? I've never needed code folding in the 5+ years I've been programming (in C,C++,Java).

Have you in fact tried it? The neat thing about code folding is permitting you to focus on the code you are currently writing/editing. If the editor has the right idea of how things are delineated in the language you're coding in, stuff you aren't looking at can be collapsed, and expanded when you do need to look at it.

Given the number of editors that implement it, I'd say more than a few folks use the feature.

As for code portability...I use some obscure operating systems from time to time, and the most supported platforms for a piece of software is GCC. This means if we write our code in ISO C, it should be extremely portable. I say this because there are many ISO C compliant compilers. Thoughts?

GCC covers most bases, but with costs. Chances are, you write your code on a Windows or Linux box with an X86 architecture. If you want your code to *run* on something else, you must set GCC up to cross-compile to the target architecture, which is non-trivial to do. (Given you work on diverse environments, I'm sure you've had practice at it.)

Scripting should be done in a shell, or external program. Perhaps the same way Acme does it (not with Edit command, but |<>...).

The advantage to scripting in an editor is that the scripting is in the editor scope. Emacs is a classic example: it's an interpreter for a dialect of Lisp, and most of the editor is written in the dialect of Lisp it implements. This makes it extremely extensible, as you can write Lisp code to make it do anything you like, and people have. Emacs these days includes modules to read/reply to email, read/reply to Usenet news, and even play games, as well as interfaces to compilers, debuggers, class browsers and the like.

(And note that back in the day, the assumption on Unix boxes was that you would run emacs when you logged in, and it would be your shell, and you would do everything from within it.)

Scripting in the editor needn't be that elaborate. Most editors have a macro capability that lets you record keystrokes to perform a function as a macro and repeat it as needed. The next step up is conditionals, and the ability to make decisions in the script as to what actions should be taken depending on circumstances.

The Unix inspired ability to pass things to other programs isn't antithetical. One of my favorite "tiny" editors back in the MS-DOS days was Dr. David Nye's E. It edited files up to the size of available memory, had search and replace, block move/copy/delete, and settable right and left margins, and did it in a 5K executable. E let you define function keys that ran batch files. Create a batch file called F3.bat, for instance. Press F3 in E. E would write the current editor buffer to a temp file, she;ll to DOS, and run F3.bat, passing the name of the temp file to it. F3.bat could run an external tool on the temp file, like a sort utility, and save it. When F3.bat completed, E would reload the changed temp file and you continued editing.

(The main limitations to E was that a 25x80 screen size was hard coded, and due to the way it stored text in RAM, lines were limited to 80 columns, and silently truncated if longer. I kept E on a RAMdisk for quick and dirty edits, but had to be mindful of line length limitations.)

The design needs to include a mechanism to some how pass script/parameters elegantly to outside programs, as well as support for syntax highlighting.

That I agree with. --DMcCunney


Out of curiosity, lf, what editor(s) do you currently use, and why?

I have both Windows and Linux here, and spend time in each. I have more than one editor installed in each OS, and which I use depends on what I'm doing.

In Windows, I spend most time in a fork of Florian Ballmer's Notepad2. Notepad2 is based on Neil Hodgson's Scintilla edit control, which gives it code folding and syntax highlighting for an assortment of languages. It uses a registry hack to replace Windows Notepad as the default Windows text editor, and gets the not because it starts up very quickly. It wouldn't do for major development projects, but it doesn't need to.

I also have GnuEmacs, VIM, NotepadPlusPlus and an assortment of others installed.

In Linux, my usual editor is Geany, another Scintilla based editor, designed to be a lightweight IDE. But as in Windows, I have other things, including Emacs, Vim, Bluefish and a few other things.

I don't think there can be a "one-size fits all'' editor, and don't really care. I use the best tool for the editing job I'm doing.


If you didn't care you wouldn't be contributing (constructive criticism) to this now would you!

Oh, I care, in that I want a tool suited to the job. I just don't expect to use the same tool for every job. For instance, I have a Leatherman Wave multi-tool. It's extraordinarily handy, and travel with me everywhere. It has a knife, saw, file, Philips head and several sizes of flathead screewdrivers, scissors, awl, and a couple of other things. It will do in a pinch if I don't have that particular dedicated tool handy, but that's "in a pinch". By preference, I use the dedicated tool. The multi-tool can't do it as quickly or as well.

I used to be a huge vi/m fanatic. It's only when I went to try out Plan 9 about 2 years ago that I realized the vi-way of doing things simply didn't make sense in a graphical environment. After having tried sam and acme a lot over that time span, I've got to say sam was the closest thing to a perfect editor I have ever touched. On Windows I use Notepad++, Eclipse, Visual Studio, gvim, and the odd time when I can't get Notepad++, plain old notepad with a terminal and file manager open. This is essentially a setup that can be established on any system. The major downfall is notepad doesn't recognize changes of the disk files, so I end up having to go the extra step and open them up again after I've run a command on them. On Linux I've only ever used nano, n/vi/m, and gedit. With plan9port I use sam when I can.

I learned vi back in the AT&T System V R2 days. You needed to know it because emacs or whatever else you might prefer might not be available on the machine you had to work on, but vi would be. It was a bit of a rude shock coming to it from the PC world, and PC editors like WordStar had been a rude shock coming from a mainframe world where TSO/ISPF was the norm, and 3270 block mode terminals had a different notion of "full screen editing". They were block mode, and you moved the cursor around the screen, made your changes, pressed Enter, and the entire screen was sent to the host. The character at a time I/O of PCs and the like was a new environment.

(See Bernard Greenberg's paper on Multics Emacs, at for some background on this sort of issue. Multics didn't do asynchronous character mode I/O, so implementing emacs posed challenges.)

Why does architecture matter? Because people will always want something better and spawn another. Why else would we have so many (besides licensing issues and profit)? Sure, there's a 99% chance I'm always going to be working on an x86 based machine. What happens though when something like ARM becomes even bigger than what it already is? I would still want my text editor to be available. It's an excuse to just say "you'll most likely only ever need this", at least in this case :) (because this *is* TheIdealEditor!).

Architecture can't help but matter, since you probably want to edit on the architecture you use, and that requires an editor that will run there. But we have so many because everyone has their own idea of what an editor ought to be, and it sometimes seems like writing an editor is a five finger exercise for programmers.

Some editor designs became popular and influenced editor development. vi/Vim? is one example. The number of different things that call themselves emacs is another. Use of a command line in the editor, derived from IBM usage is a third.

Now that I think about it, binary editing should probably take place in another editor. I suppose "drilling down" into text encoding was a bad idea. :)

Not bad, exactly. Just a bit pointless. It's one of those jobs best dealt with by a dedicated tool.

We are thinking two different kinds of scripting then. I was thinking more along the lines of "ok, time to write a script that manipulates this text", which can be run in shell. Actually scripting of the editor I've never thought of. Maybe it's because if people are writing plugins, they might as well be patches or something...although that could be disadvantageous to many people, having to recompile.

You can write a script to manipulate text outside the editor, or you can write a script to do it in the editor. It's a "six of one" thing.

Maybe *something* like emacs, but not quite? Expose basic methods and attributes of a regular text editor as an API? This way "plugins" could be written for things like code completion or syntax highlighting...

Maybe. One of the things I've looked at now and again is stuff like Modula3, which is an operating environment as well as programming language. The editor is a module of the environment, available anywhere. Editor functions can be used on whatever is displayed in a window in your terminal.

In that respect, it's a bit like using emacs as your shell. You can run a shell in an emacs window, and I/O is redirected to/from that window. You can use emacs to edit on the fly what you send to the shell as commands, and to massage what the shell sends back as results. (If memory doesn't fail me, similar things are possible in sam.

Yeah I've used code folding, I always end up A) Forgetting about it or B) Opening and closing folds a lot. To me, doing :/^myfunction in vi (or sam, or anything that supports regexp searching) is more than enough to quickly find code. Map it as a key macro and you're off. If you can't focus on single function at a time...Well maybe code folding IS for you :) Maybe starting an editor that has the folds all closed and only exposing the function name would be helpful...

Fair enough. It's one of those features that doesn't work for everyone. The editors I use at the moment generally have it. Whether I use it depends upon the task. Most of what I do currently is quick and dirty edits on short scripts. Not enough code to bother folding to narrow to the part of current interest.

I wish there was more activity here- this may end up just being DMcCunney and me arguing forever!

I'm not actually arguing at the moment. I'm just trying to clarify assumptions and definitions so it's clear what we might disagree on.

But the wiki isn't really a good place to have this sort of discussion. One of the things Ron and I have been discussing is a mailing list associated with the wiki, as better suited for conversations like this. Is it something you might be interested in? --DMcCunney


But the wiki isn't really a good place to have this sort of discussion. One of the things Ron and I have been discussing is a mailing list associated with the wiki, as better suited for conversations like this. Is it something you might be interested in? --DMcCunney

I would be extremely interested in a mailing list for conversations like this!

Would this mean I should delete this page?

Nope. It can stay for historical interest. I'll talk to Ron about implementing the list. I could do it now, but a background concern is that we are looking at migrating TextEditors to different wiki software. The wikiwiki software we are using has limitations that are beginning to bite. (Like the function to add a userid as log in as that ID is broken, and neither of us understand why. We may have hit an unspecified limit in how many IDs can be created.

I'd love something that made the sort of classification we like to do easier. I did a lot of work breaking out editor families and populating them, but that's a manual process. I'd like a "What feature is in what editor?" matrix, but that's a daunting amount of work.

We'll see.

Meanwhile, email reaches me at dennis dot mccunney at gmail dot com. Feel free to drop me a note and we can chat some more. --DMcCunney

I've long felt that the ideal text editor would be a very simple core program that simply allowed mouse, keyboard, and screen to interact via customisable menus, programmable keys, and pickable lists, but that all the really cool stuff would be done by separate small programs so you loaded only what you needed and your text editing environment suited just you. Each person would have their own different requirements filled by such a system. It owes a lot to the Unix philosophy.

I use Linux and I have a few text editors that I like to use, none completely filling my needs, but I've written lots of tiny scripts that are attached to icons on the desktop, letting me do things like insert HTML markup around selected text, insert the current date and time in any of various formats, wrap selected text, and dozens of other actions. The icons, under the file manager ROX even let me add many actions into a popup menu when I right-click the icon. The scripts work on any text, anywhere, so I can use them not only in any text editor, but also in chats, and blog and wiki posts, or even when renaming files or saving files in dialogs. They have almost become my ideal text editor. I say almost because I still haven't found the ideal core editor for my main text editing work. I use Geany, which is nice, but a bit bigger than I like, Leafpad, which is nice and small, but a bit clunky, Beaver, which is not bad, and several others, such as gedit occasionally, ged and mp rarely. I've uploaded some examples of these RoxApps? to my site at (the download link is in that page just before the first screenshot of the icons). That page also explains how they work and what I eventually hope to achieve.

Back when I used MSWindows I fell in love with TextPad -- close to the best text editor I ever used. Its biggest drawback was that the macro language is closed and only usable by recording keystrokes.

Before that, when I used the Amiga I constantly used and customised Matt Dillon's absolutely brilliant GUI text editor, DME (Dillon's Macro Editor), which was a truly amazing piece of work. Not only could you rewrite the entire menu system from inside the program, and reprogram the keypresses to do anything you wanted, it had its own scripting macro language complete with conditionals that asked what was currently under the cursor, and as with most Amiga programs it used ARexx as an interprocess scripting language, allowing me to use DME to control raytracing programs, 3D modelling programs, paint programs, and sound programs. All this in just 57K. I had lots of small scripts that I could call up from inside DME, some from keypresses, some from custom menu items. It gave me more freedom than anything I've had since.

I'm a writer and artist who does some programming. All my books are written using text editors because I despise wordprocessors. (Incidentally, all my stories and books can be read online or downloaded for free at my website if you like science fiction.) --miriam

HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences
Edit text of this page | View other revisions
Last edited May 26, 2015 4:31 pm (diff)