Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Softpanorama Bulletin
Vol 14, No. 03 (July, 2002)

Bulletin 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007
2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018

 Note on Size-based Classification of Text Editors

Dr. Nikolai Bezroukov

Version 0.30


Copyright 1998-2001, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.


Contents

Abstract

The article presents an attempt to understand correlation between features of text editors and editor size based of tasks each weight category performs better and1 propose size based classification of editors

The concept of "editor weight" is useful for explaining why most programmers use several editors (usually three: standalone lightweight editor like Notepad, midweight editor like Vim, Kedit or SlickEdit and heavyweight editor like Microsoft Visual Studio .Net, Emacs, etc).

That suggests that there are tasks for which one editor of a certain size suit best and perfoming of which with the editor of a different category is less efficient despite the additional power it might provide. This paradox that most programmers use several editors while leading one would be more efficient can be explained by the hypothesis that editors can be classified into three distinct categories and that each category of editors has its own unique set of features In this case one size does not fit all. We will distinguish 

The main idea here that there are tasks that are better, quicker performed by lightweight editors and they're are tasks that are better performed by midweight/heavyweight editors, so those categories of editors develop in different directions.

The concept of "editor weight" is useful for explaining that we need not one but several editors. This paradox that most programmers use several editors while leading one would be more efficient can be explained by the hypothesis that editors can be classified into three distinct categories and that each category of editors has its own unique set of features In this case one size does not fit all. We will distinguish 

The main idea here that there are tasks that are better, quicker performed by lightweight editors and they're are tasks that are better performed by midweight/heavyweight editors, so those catagories of editors develop in different directions.

Introduction

I abhor a system designed for the "user", if that word is
a coded pejorative meaning "stupid and unsophisticated".
-- Ken Thompson
 

I would like to stress that an editor is probably the most important tool for programmers, therefore one needs to choose wisely. A popular consideration that easy to learn editor (for example Pico or Notepad) is the best does not withstand any critique. An editor is too important tool for programmers to settle on the basic capabilities and it's a big disadvantage to select a mediocre or even primitive solution just because it's simple to learn.  Any professional programmer needs a professional editor.

Any professional programmer needs a professional editor

In case you are a casual user simple editor might make sense, but still lack of  growing space is a disadvantage.  But for everybody else this is one of the most serious mistakes that you can make -- a mousetrap to avoid. You do need a powerful editor or you will regret your choice the rest of  your professional career (that in case you will be able to switch somewhere during active phase of your career; otherwise you have pretty good chances to die in happy ignorance ;-).  Bad habits are difficult to change and usage of a primitive editor is such a bad (and pretty widespread) habit.  Naive tales like "How I like Pico (or Notepad)" are amusing the same way as stories about people who voluntarily deprive themselves of basic staff and enjoy this state of deprivation.

The main problem that I see is that people tent to stick to whatever editor they got used to first and even became emotionally attached to the "first choice". It happened to me and it took me a lot of efforts to move from a primitive editor to a decent one. Often this "first choice" is a pretty mediocre editor that is/was widely used in a particular environment, but that not necessary is able to provide high performance in all typical editing tasks.

In this paper we introduce three categories of editors and discuss how each of them can help a programmer be productive. The author argues that a professional programmer need to muster at least two editors to achieve optimal productivity.

 Lightweight Editors

Those editors are usually used for making small corrections in program files or configuration files. They rarely used for editing text documents, even plain text documents. Based on this range of tasks they usually have several distributing characteristics:

Lightweight editors usually have no multi-windows support. One important role for lightweight editor is to serve as a default editor in the file managers, see my OFM  page for a discussion. IMHO the compatibility and ease of use within OFM and integration with it is really important.  For this reason in Unix/Linux environment I would recommend mcedit. Despite some severe limitations, mcedit is well integrated with Midnight Commander and this combination provides unique productivity gains despite its shortcomings as an editor. See my super-lightweight links for additional details.  If you do not like mcedit FTE Text Editor  seems to be OK too. For Windows suitable candidates can be found in a category Notepad replacements ;-). Among them NoteTab Light looks especially promising and can be used with Total Commander.  Some people like QEedit (now Semware editor), but I don't. 

The obvious choice for Unix users is good old vi.  But I feel that it outlived its usefulness: unless absolutely necessary you probably should not use plain-vanilla Vi supplied with Solaris or HP-UX. If you can, use vim instead: it's a much better implementation of the same paradigm and it even supports some Perl integration. On current PCs with 3 GHz CPU and fast drives VIM6 can probably be used as both lightweight and mid-weight editor. Actually light version of vim is used instead of the standard vi in most Linux distributions.

Mid-weight Editors

Often have a standalone executable that is approximately less than 512K. This class includes some powerful professional editors like THE. In addition to features present in lightweight editors they should have:

Still usually this class of editors not necessary has folding/condensing/outlining ( like all command in THE). Probably one of the best examples of midweight editors can serve vim. BTW it  has a very good windows port. If you use Java then  jEdit - Open Source programmer's text editor might be close. GWD Text Editor  also can be considered. JED is also very close and has a macro language.

In Windows environment Microsoft Visual Studio editor is pretty primitive, but it has a scripting language support and can come close to the requirements above.   Moreover in a particular environment of Visual Studio it's almost a standard editor. 

Important Note: support for piping and using Perl or other scripting language is a very useful feature. that's why vim6 is probably one of the best choice for midweight editors, but only for qualified users with Unix experience.  For Windows users it might make sense to use a heavyweight editor instead. 

OK, I will not go so far as to outlaw all other mid-weight editors in existence in favor of  open source editors. Proprietary editors sometimes have important advantages, but still some of open source editors  are very portable, have a reasonable quality and probably will be supported for the rest of your professional life. Among them I would recommend to try both THE and Vim6. Vim6 is generally underappreciated editor that is especially attractive for users who use Unix extensively as vi is a standard editor on all commercial Unixes and you need to know it to be productive. For users that predominantly use Windows it might make sense to use heavyweight editor instead: you can buy Slickedit and it's a pretty much OK editor, if you have company funds available. It has non-standard scripting language and it sucks, but otherwise the editor is OK. SlickEdit is portable to all major flavors of Unix including Linux. The main drawback is that it's too expensive for home/hobby use.  If you never use Windows MultiEdit might be an interesting choice too. It has very good windows management capabilities.

The principal advantage of  VIM6 as a vi-style editor in comparison with other lightweight editors is the support of processing of the buffer by arbitrary external shell filters -- a very elegant and nice feature. Another very interesting capability and the ability to executing shell commands without leaving an editor. The ability to execute the content of the buffer as simple script is also pretty unique and quite useful. But cut and past operations in vi are not that good (although in GUI version of VIM6 there are acceptable). What is really important is that VIM6 even supports folding. Missing scripting language are OK for midweight editor, but  not very flexible multiwindows capabilities might be a disadvantage.

If VIM6 looks too idiosyncratic (and that is usually the case for Windows users, although VIM Windows implementation is really decent) and you still want OSS editor my recommendation is to try JED. It does not support piping the buffer but it has a better multiwindows and scripting language support that provides a lot of very useful functionality.

Heavyweight Editors

This class of editors has no size limitations and should have GUI version that should be able to take advantage of full GUI capabilities like different fonts, overlapping windows, etc.  Thus, most  heavyweight editor generally does not have a command line version (although MultiEdit for DOS and Emacs are notable exceptions) 

The second requirement is to have a built-in ftp-client, so that the editor can be used in a cross-platform environment.

I consider this kind of editors as one of the most important programmer tools that programmers should use for daily work. This class is represented by such well-known names as XEmacs, Kedit, MultiEdit, SlickEdit and even MS Word. GVIM 6.1 is close but it's not here yet -- no decent macro language. Some TCL-based editors, for example Tkedit might also came close.

Required features for this class of editors include:
 

Among open source editors the natural choice would be XEmacs but it looks somewhat outdated for me. Still it is a very flexible editor with Lisp as a scripting language. I definitely prefer Kedit (or any other Eastern Orthodox Editor) but it's not available for Unix/Linux. SlickEdit is but it has a proprietary macrolanguage.

XEmacs is capable to meet almost all requirements listed above and for many programmers it serves as an pseudo IDE. As one XEmacs user put it Xemacs is my operating system, Linux is my device driver ;-)

One of the most problematic things with heavyweight editors is that it is not easy to learn all those capabilities and its easy to forget all what you learn due to absence of practice. As I already mentioned that is especially bad for scripting. The best cure for this problem is to study the editor that supports a standard scripting language.  Currently there not that  many editors that support standard scripting languages. Eastern Orthodox Editors support REXX, some editors support TCL ( for example Tkedit) and Microsoft editors can be used with JavaScript or VBscript and that's about it.

REXX, the  traditional for EOE scripting language is no longer popular and thus two other variants might be a better deal (JavaScript or  TCL) but it's user dependent and should be waited against other capabilities of the editor.  There is no easy choice...

If you try to learn to use a more powerful editor after learning a simple one like Visual Studio editor, then first you will feel yourself like a foreigner. And usually at the beginning you will hate this new clumsy editor. But after a while you will never be the same -- you will start to appreciate features that they provide and even if you will not switch, you will definitely be more productive with your old editor. This reasoning also applies to windows users learning vim -- it's an old editor, but it does have several unique convenient features that are usually absent in  flashy DOS/Windows-style editors (for example the ability to process any part of the buffer with the standard Unix filters like indent or Perl interpreter).

I was lucky enough because at various stages of my career I used (and for some wrote quite a lot of macros) several different middleweight and heavyweight editors including MultiEdit,  Orthodox editors (Xedit/KEDIT/THE family), Vi family (vim, vile, etc.) and MS Word (BTW not a bad programming editor with quite powerful outlining, but no folding/slicing). It's interesting to note that  MS Word is quite suitable for literate programming and some of my friends used it as such.  

I also used a dozen or so lightweight editors like  FTE, QEdit (now Semware editor), WordStar-based Borland IDE editors, DOS-edit, mcedit as well as special purpose editors like Heavy Metal Pro or FrontPage (please note that both FP2000 and FP2002 are scriptable using VBA). But of course I do not know them as well as I know THE/Kedit line or MultiEdit.

This class of editors should support all features of middleweight editors and more. You can think about them as a GUI-based midweight editors, or like the best editors money can buy, kind of Cadillac of editors ;-). The most important feature of a heavyweight editor in the proposed classification is folding/outlining and a comprehensive scripting language support.

Naturally the most important and quite religious question is what scripting language in the best in the editor -- there are so many of them. As an orthodox preacher I would like to warn you against joining some obscure cults ;-).  You should chose the scripting language wisely -- preferably the one that you already know. Stay away from proprietary C-like scripting languages -- IMHO they are difficult to remember unless you use them n daily basis, which is a very rare mode of work (that happened with my MiltiEdit macro programming skills -- they simply disappear).

TCL, JavaScript, REXX, Lisp are all applicable outside the editing domain and that's an extremely important consideration. If you use Perl them VIM or other editor that support processing of the buffer with scripts is the best. To master scripting language used in the editor is really important, but you will have almost no chance to achieve this if you do not use the language for solving other tasks. See my overload page for details. My own preferences are with REXX, TCL and JavaScript (can be used instead of VBScript in Microsoft products, for example MS Word). I actually would prefer that THE editor supported TCL along with (or even instead of) REXX.

The best solutions is when you editor scripting language is used as the shell language of your OS, but this is currently achievable only Windows (VBScript/JScript), OS/2 and Amiga (with REXX).  Linux and all other flavors of Unix unfortunately are is worse shape. Still one can try to use TCL as there are editors and Orthodox file managers that are written in this langue and that naturally support it as a macro language.

Anyway the choice is really difficult and I would like to stress it again, that (unless you are a language freak) it's wise to chose and editor that supports a scripting language that you already know and already use in other tasks, if possible.  But often this criteria is imporsible to meet. For example I do not know any decent mid-weight editor that support Perl -- probably the most common scripting language in Unix world.   If we speak about Unix then our choices are essentially limited to BeanShell, TCL and REXX and Lisp

Anyway, please use a decent editor for complex editing jobs. Believe me this is really important !  I know some quite gifted programmers/administrators who never managed to learn decent editor with scripting and folding. They are actually depriving themselves of one of the most important tools and artificially make programming and Unix (as well as Windows) administration much more complex than it is.

Commercial editors like MiltiEdit and Slickedit  are OK, but Multiedit is not-portable and SlickEdit is expensive. Still Slickedit has reasonable folding support.  But its weakest point is support of  rather strange, proprietary scripting languages which bears only a superficial resemblance to C/C++ but have no classes. It uses both typed and untyped variables.. The syntax is, to put it kindly, eclectic, held together with duct tape and bailing wire. The designer has never heard of the concept of orthogonality. Every feature of the language comes with a list of odd exceptional conditions under which it does not work. It is the quirkiest most ad hoc, asymmetrical language I have ever encountered, and probably the hardest to learn. However, the internal pcode it uses is reasonable fast and gets the job done. All the common methods are written in native code for speed. You learn it mainly by studying the existing source code.  Those comments generally are applicable to Multiedit too. Still both SlickEdit and MiltiEdit are pretty powerful editors that have advantages that might outweigh disadvantages, especially in windows environment. 

Note that MS Word (and Word Perfect) are usually classified as document editors. Paradoxically Ms Word is a pretty decent programmable editor (using VBScript or Jscript). One should think about it as a literate programming paradigm tool. I do not know about WordPerfect much but this is probably true about WP too. 

Other useful features that you need to consider include: Context Tagging, Dynamic Difference Editing, FTP Support, a Functions/Class Browser, Dynamic Tagging and a Code Beautifier.

Of course Emacs is a classical example, but it suffers from a rather idiosyncratic scripting language (Lisp)... It is interesting to note that such a great thinker in computer science as Professor Donald Knuth is an XEmacs user. But I actually am not impressed with Emacs/XEmacs. May be that's because of my REXX and Perl background and that fact that Lisp is not a useful language for me outside the editor. 

MS Word is another example from another platform with another idiosyncratic scripting language (VBA). It main advantage that it supports HTML, and has a very powerful outlining capabilities, but again I am not a VBA user ;-). That means that  for me the attractiveness of MS Word as a super-editor is pretty limited. Probably even Word Perfect might be a better bet for a new user (due to better XML support and the same VBA macrolanguage), as probably any powerful XML-based editor (but probably Microsoft bridged the gap did a good job with XML in Word 2002), but I really do not know as I still is mainly an XHTML user ;-). What is really interesting in MS Word is that some programmers successfully used it as a programming editor in Windows environment (and that is a long tradition, actually starting from version 4.0) -- paradoxically it is one of the best implementations of the literate programming paradigm. Ms Word supports automatic construction of index, has powerful outlining and other features that are primary literate programmer instruments.  It's not very difficult to write an extraction of programming module tool to send part of  Word documents to compiler. BTW Thinking in Java was written this way. See my altoffice page for more details.

The latest MultiEdit 9.0 supports  HTML editing, has (limited) folding capabilities and thus can be considered to be a heavyweight editor. It's an excellent editor -- IMHO for years it was the best implementation of a programmer editor in the DOS environment. But this is Windows only implementation, no Unix ports yet and I do not recommend to use non-portable editors :-(.

Webliography

Nikolai Bezroukov Orthodox Editors

Softpanorama Orthodox Editors Page



Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019