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. 02 (April, 2002)

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

Orthodox Editors as a Special Class of Advanced Editors

The introductory paper Orthodox Editors introduced some ideas on which this page was build. Here is the abstract of the paper:

This paper tried to introduce a new concept: orthodox editors as a special category of editors. All of them have command line set of commands and respective glue macrolanguage. We have found two such families:

We define the notion of  "orthodox editors" as having the following distinct features:

  1. They have a well-defined command set that is comparable in power to GUI based commands and command line can be used to enter editor commands. For some of them (vi - line ) that comes naturally, from the fact that they were initially designed for typewriters. 
  2. They permit doing any editing task using keyboard  (although mouse can speed up or simplify many of those tasks and is not rejected in the extremist way)
  3. They use a standard scripting language as a macrolanguage (TCL, REXX) or unique for the application (YASL  - yet another scripting language) like in vim 6 as a macrolanguage. It serves as a glue for the command set implemented by the editor. With some reservations we can accept  a unique for the application (YASL  - yet another scripting language) like in VIM. This is definitely less attractive solution as it is difficult to master the language that you use only for a specific application (in this case an editor).  The same consideration is applicable to Emacs. 
  4. They support folding (all command in XEDIT and its derivatives; folding capabilities in VIM )
  5. They distinguish between editing buffer and the windows in which this editing buffer is displayed allowing multiple windows to display the same buffer.
  6. They support regular expressions
  7. They permit processing selected part of the editing buffer or all the buffer via pipe connected to external command (! command in vi)
  8. They support multiple views of the same editing buffer.
  9. They allow piping in output from arbitrary pipe into the current position of cursor, selection, or all buffer as well as exporting a selection or all buffer as an input stream for an arbitrary pipe.  

This article is a modest attempt to create a basic classification useful for further studying this important class of editors. The author argues that this class of editors can serve as viable mid-weight editors for programmers (see a companion paper A Note on Size-based Classification of Text Editors for this further discussion of related ideas).

This article is a modest attempt to create a basic classification useful for further studying this important class of editors. The author argues that this class of editors can serve as viable editors for programmers providing despite Spartan interface rich functionality absent in almost any other editor with possible exception of vi and its derivatives. Despite integrating a macro language they are actually pretty small, mid-weight by some standards (see a companion paper A Note on Size-based Classification of Text Editors for this further discussion of related ideas).

Please note that both subclasses of orthodox editors were pioneers in introducing several important for any modern editor features, features that unfortunately still are absent or poorly implemented in most other editors: 

This paper explores two sets of  deep interconnections that were previously unnoticed in the literature:

Actually the second point was the main reason that I decided to use a superclass term "orthodox editors" that includes as subclasses both XEDIT editors line and VI editors lines. Not only because I like to invent new terms (that goes with Ph.D ;-), but I really see deep similarities between them and their connection to a similar phenomenon that I studied earlier in case of File Managers (see OFM page for details). Those tools are representative of a different approach to GUI interface then Apple GUI or Microsoft GUI (which are converging). Interface that can be called "Orthodox Interface".  And this Spartan interface with ancient-looking, "half-baked" GUI with command line present give users important and unique capabilities that are missing in other similar "pure GUI" Tools. They survived because they are capable of giving advanced users the ability to achieve an extremely high productivity, beating competition. Although some design decisions in those editors were dictated by limitation of old hardware they withstand the test of time and proved to be useful and extremely productive tools for modern environments.

Read more

Another interesting for me issue is the value of editors of different sizes (lightweight, mid-weight and heavyweight). My thought on this issue are reflected in another paper  A Note on Size-based Classification of Text Editors  Here is the 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.

Read more

Most programmers spend  a lot of time editing the code (may as much as 40%). If that's the case, finding the best tool available and, if necessary, spending a few extra dollars for it definitely is a good investment.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

See also

Top

Design issues:


Articles

The Craft of Text Editing by Craig A. Finseth -- free e-book

Preface
Introduction: What Is Text Editing All About?
Chapter 1: Users
Chapter 2: User Interface Hardware
Chapter 3: Implementation Languages
Chapter 4: Editing Models
Chapter 5: File Formats
Chapter 6: The Internal Sub-Editor
Chapter 7: Redisplay
Chapter 8: User-Oriented Commands: The Command Loop
Chapter 9: Command Set Design
Chapter 10: Emacs-Type Editors
Epilogue
Appendix A: A Five-Minute Introduction to C
Appendix B: Emacs Implementations
Appendix C: The Emacs Command Set
Appendix D: The TECO Command Set
Appendix E: ASCII Chart
Bibliography
Book Index


Folding

See also: Eastern Orthodox Editors (Xedit/Kedit/THE) are probably the oldest (Xedit seems to be around on VM/CMS from early 70th) and the most widely used folding editors. Although it's hard to teach old dog now tricks vim 6.0 will support folding.  I consider folding (actually there are several types of folding -- one is slicing (and in orthodox editors command All, the other is outlining as implemented in Ms Word and other word processors and some HTML-editors) an extremely useful feature. Once you have got used to the folding paradigm, you will not want to use a flat editor again! That's why I consider EOE family of editors so important.  Franz J. Kurfess -- Master's Project Topics at NJIT   include folding

comp.programming.literate FAQ

9.5. Fold2Web

Developer: Bernhard Lang <[email protected]>
Version: V0.8
Hardware: MSDOS
Languages: All (must allow comment lines)
Formatter: LaTeX
Availability: Anonymous ftp from:
kirk.ti1.tu-harburg.de (134.28.41.50)
/pub/fold2web/readme
/pub/fold2web/fold2web.zip
Readme: In distribution

Description:

The idea behind the Fold2Web tool is the following: A programmer can write his program source with a folding editor and later map the folded source files automatically to WEB-files. The generated WEB-files can then be modified by inserting required documentations.

The advantage by starting program developement with original sources is to get short design cycles during the compile/debug steps. By using a folding editor the global structuring information can be already captured in folds during this developement phase. Fold information is typically stored in comment lines and thus will not affect the
efficiency of the compile/debug design cycle.

Some folding editors and a folding mode for the emacs are available (e.g. see our FUE folding editor for MSDOS machines which is a modified micro emacs. Pick it at kirk in directory /pub/fold2web).

After reaching a stable version of a program source its time to convert the source file to a WEB-file and do the program documentation. Fold2Web is written to convert folded source text of any programming language to nuweb files. The folded structure is kept by mapping folds to scraps. Fold markers which differ between languages due to different ways of specifying comments can be configured for each language.

Good results can also achived when given but poor documented program sources have to be modified. Such sources can be folded using a folding editor to extract the global structures. This offers a global view tothe program structures and help to understand its functionality. Furthermore the program code is not affected, only comment lines are
inserted. Once folded the program source can be automatically translated to a WEB document using the above tool.

Illustrative Browsing A New Method of Browsing in Long On-line Texts

Fe User Guide

A few words on the design of fe

After working with Origami for many years, both as user and developer, I have decided to implement a new folding editor: fe. There are a few basic design decisions which make it different from Origami:

Origami is partially written in its extension language. While being more of a hack in the beginning, it has changed to a full programming language. As such, it takes time to be learnt. Code written in it is not well usable by most people who don't know it. The conclusion for fe is not to support any extension language, neither a homebrew one or a standardised language, like scheme. Instead, fe is implemented as a library of basic editor primitives. Its is easy to write your own editor by using that library. fe can be modified easy without having to learn a new programming language. The editor also stays small and elegant this way, while Origami has to offer zillions hooks for extension functions.

Origami implements folds as double-linked n-trees, with nodes being single lines or folds. This allows quick manipulation of folds or lines. But region oriented functions become hard to implement and are mostly not too quick any more. fe uses a gap buffer to store text, folds are represented as meta-characters in the flat buffer. This means basic fold primitives are slower than in Origami, but more complex and region oriented functions are faster. During development of the first prototype of fe, I found many functions in Origami not to be as canonical as they should be after I implemented them in fe. From my past experience, the performance of typical personal computers to have increased by a factor of 10 every 5 years in the last decade, so the circumstances for editor design have clearly changed over time.

Folding has its merits, because it adds a structure to flat files. But, it also means that by bad structure design and badly commented folds the file will get harder to understand, not easier. This can happen up to the point where you want all folds to be gone to see what the file contains. If you need to keep many folds open during development to see their contents, you are probably preparing that situation at least for others. Although in general I don't like programs forcing me to do something, fe makes an exception here for two reasons: If the structure is obvious, you want the editor to close folds for you automatically. If it is not, you want to recognize that before it is too late. For that reason, fe closes all folds when you leave them. If you want to transport code from one fold to another, just split the current display and edit the file at two places. If both places are sufficient far away from each other, that's what you even had to do if you could leave folds open. \"}}}

Richard King Home Page

Published Papers

A user interface for a multi-user folding editor

Animation techniques for folding editors

Masters Thesis

What is a folding editor -- not very correct, but still interesting discussion

Most folding capabilities in editors such as GNU Emacs and most folding editors such as Origami and fe, are inspired by the Inmos Transputer Development System. After several years, folding/outlining capabilities in text editors are not as exotic as they used to be, but they are still far from being well known. This document explains what "folding" is all about.

A folding editor extends the principle of tree structured directories to editing text files. This allows the simultaneous display of large amounts of text by folding sections of text away behind a descriptive heading. This results in a tree structure very similar to a subdirectory structure of, for example, UNIX. By suitable structuring of a text it should be possible, in most circumstances, to ensure that no display exceeds a single screen at any time. To access text that is folded away, you open the fold, in which case the contents are displayed in context of the surrounding text. The advantage of this system is that it eliminates the need for seemingly endless paging through long files to find the section of interest, allowing you to move down the tree structure, following the (hopefully) descriptive headers to locate the text you require.

Internet Parallel Computing Archive Tools Editors Folding-editors -- links to several implementations

Hybris -- a very interesting implementation of scrollable nesting -- it's actually more looks like outlining, but probably can be used for folding. anyway this is something new and no other editor seems to be able to do the same trick.

GRASP Graphical Representations of Algorithms Structures and Processes -- the idea of syntax diagrams

JED -- the latest version has folding

Internet Parallel Computing Archive Tools Editors Folding-editors -- I believe that folding is a must for any editor. Here we have slightly outdated and incomplete collection of relevant links.

Fe User Guide   -- A Folding Editor, which aims to be fast and small.

After working with Origami for many years, both as user and developer, I have decided to implement a new folding editor: fe. There are a few basic design decisions which make it different from Origami:

Origami is partially written in its extension language. While being more of a hack in the beginning, it has changed to a full programming language. As such, it takes time to be learnt. Code written in it is not well usable by most people who don't know it. The conclusion for fe is not to support any extension language, neither a homebrew one or a standardised language, like scheme. Instead, fe is implemented as a library of basic editor primitives. Its is easy to write your own editor by using that library. fe can be modified easy without having to learn a new programming language. The editor also stays small and elegant this way, while Origami has to offer zillions hooks for extension functions.

Origami implements folds as double-linked n-trees, with nodes being single lines or folds. This allows quick manipulation of folds or lines. But region oriented functions become hard to implement and are mostly not too quick any more. fe uses a gap buffer to store text, folds are represented as meta-characters in the flat buffer. This means basic fold primitives are slower than in Origami, but more complex and region oriented functions are faster. During development of the first prototype of fe, I found many functions in Origami not to be as canonical as they should be after I implemented them in fe. From my past experience, the performance of typical personal computers to have increased by a factor of 10 every 5 years in the last decade, so the circumstances for editor design have clearly changed over time.

Folding has its merits, because it adds a structure to flat files. But, it also means that by bad structure design and badly commented folds the file will get harder to understand, not easier. This can happen up to the point where you want all folds to be gone to see what the file contains. If you need to keep many folds open during development to see their contents, you are probably preparing that situation at least for others. Although in general I don't like programs forcing me to do something, fe makes an exception here for two reasons: If the structure is obvious, you want the editor to close folds for you automatically. If it is not, you want to recognize that before it is too late. For that reason, fe closes all folds when you leave them. If you want to transport code from one fold to another, just split the current display and edit the file at two places. If both places are sufficient far away from each other, that's what you even had to do if you could leave folds open.

Andys Source Code Folding Editor -- a language configurable folding source code editor


History

Salon 21st The Xy files BY AMY VIRSHUP |

FOR THE REST OF THE WORLD, XYWRITE IS HISTORY --
BUT TO ITS DEVOTEES, THE ANTIQUATED WORD PROCESSOR STILL RULES.

 Not long ago, a writer friend and I were talking software (there's a sentence I never thought I'd write) -- specifically whether we were Luddites for resisting a Windows 98 upgrade. Well, she said, she hardly felt out-of-date, since most of her publishing-world friends were still using XyWrite. I was stunned. I hadn't even heard the name in years, and suddenly I'd learned that, in a world in which six months is a generation, there lingered a dedicated cadre of loyalists to a program that hasn't been upgraded since 1993, that still runs best in DOS, that isn't compatible with most printers, and that has all but vanished as a commercial product. It was like finding out that a cargo cult was operating down the hall from my apartment.

For those of you unfamiliar with XyWrite -- the "GOD of word processors," as one poster to alt.folklore.computers recently put it -- the program was an offshoot of ATEX, which in the '80s was the standard in newspaper and magazine editorial hardware and software. It was created in 1982 by an ATEX programmer named David Erickson, who'd bought a PC and was unhappy with the word processor that came with it. So Erickson decided to write his own, and not long after he and another employee left ATEX to set up shop as XyQuest.

XyWrite was fast, it could do things no other word processor at the time could (like open two windows simultaneously), and because of the nature of the underlying programming language, XPL, it could be endlessly customized. The screen was a blank page with a command line at the top (hitting F5 would take you there), and when you wanted XyWrite to do something, you simply typed in an English-language command (such as "print" to print a file) or used one of your own custom keystrokes to carry out the task. It was defiantly not a "what you see is what you get" program, but it was extremely transparent, with all the formatting information easily viewable. And it was an instant hit among professional writers and editors, many of whom, um, borrowed their copies from their employers on a single 5 1/4-inch floppy -- mine, I confess, came from New York magazine, circa 1984.

Nancy Friedman was editorial director at Banana Republic when the clothing retailer started using XyWrite (version 2). "I loved it," says Friedman. "All of a sudden I was using this program that thought the way a writer thinks. All other word processing programs were created for secretaries -- they're all about creating standard one page documents. This one really expected that I was doing sophisticated editing and writing."

High-profile devotees included television's Brit Hume, John Judis of the New Republic and high-tech guru Esther Dyson. Critics called it the "Porsche 911 Carrera" or the "velociraptor" of word processors. And as much as they admired the software, users also loved the scrappy, down-home nature of the company: Erickson would sometimes answer tech support calls himself, and XyQuest was headquarted in decidedly unglamorous Billerica, Mass. "I was always so happy driving through Billerica knowing they were working to update XyWrite," remembers one writer who had occasion to pass through town in XyWrite's heyday. "It sounds so dopey, but that's how it was."

But XyQuest's marketing was never as good as its software, and it lacked the resources to compete with the big boys -- like WordPerfect, which the XyWrite faithful held in contempt. Then, in early 1990, IBM stepped in. The computer giant announced it was hooking up with XyQuest to create a new product, called Signature, based on the XyWrite model, and it looked like XyWrite was about to join the commercial mainstream. Instead, IBM delayed the product for a year and a half -- then, with boxes printed and diskettes ready to go, decided it was getting out of the software business altogether. A reconstituted XyQuest tried to sell the program on its own (renamed XyWrite 4), simply slapping stickers over the IBM logos on the boxes, says Tim Baehr, then a XyQuest programmer. But "sales just got lower and lower. We were bleeding money."

Random Findings

...



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