Orthodox Editors Page
Softpanorama
(slightly skeptical)
Open Source Software Educational Society
May the
source be with you,
but remember the KISS principle ;-)
Orthodox Editors as a Special Class of Advanced Editors
News
Introduction
Recommended Links
Recommended Articles
Eastern Orthodox editors
Western Orthodox Editors (VIM)
Beautifiers and
Pretty Printers
Folding
Slicing
Outlining
Ctags
Regex
PC-style light weight Unix/Linux
Light-weight win32 Editors
GUI-based programmable
Programmable Word processors
HTML programmable
Html editors
History
Humor
Etc
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 and their relation (in Eastern Orthodox family represented
by such editors as Xedit, Kedit, THE) to the concept of folding.
First we define special class of editors, that we call "orthodox
editors" as having three distinct features:
A command line editing support and respective command language that can
be some common scripting language (TCL, REXX) or unique for the application
(YASL - yet another scripting language) like in vim.
They fully support folding (all command in xedit and its derivatives)
They permit doing any editing task using keyboard (although mouse can
speed up or simplify many of those tasks).
This article is a modest attempt to create an intellectual
context for studying this important class of editors.
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
lightweight editors
(editors that does not need
installation and can be fully functional if the computer contains one
executable and a user can start editing after moving this executable to new
computer. They can They can use additional initialization and
configuration files but they should be optional of at max two files (editor
executable and optional initialization file/files)
midweight editors
should have powerful macro language,
folding and full multi-windows support. That's the category were orthodox
editors fall into.
heavyweight
editors are essentially in IDE in
disguise. Emacs is classic example of heavyweight editor, visual Studio .Net
is another example.
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.
Notes:
Those pages are written by people for
whom English is not a native language.
Some amount of grammar and spelling errors should be expected.
This is a Spartan WHYFF (We Help You For
Free) site. It cannot replace the
best teachers and
the best books.
The site contain some obsolete pages as
it develops like a living tree... Some links on older pages
are broken. Please try to use
Google, Open directory, etc. to find a replacement link (see
HOWTO search the WEB for details). We would appreciate if
you can
mail us a correct link.
Search Amazon by keywords:
Open directory
Research Index
Old News ;-)
2004
2003
2002
2001
2000
and earlier
ConText Editor
Very interesting Windows editor. Flexible customizable syntax highlighting. Well
organized features
This syntax highlighting editor supports numerous
programming languages including C/C++, Delphi, Pascal, Java,
JavaScript, Visual Basic, Perl, HTML, SQL, FoxPro, 80x86
assembler, Python, PHP, Tcl/Tk, etc (you can customize the
syntax highlighting). Other features include code templates,
customizable help files for each file type, export to HTML/RTF,
file conversion (DOS, Unix, MAC), bookmarks, commenting, uncommenting code, capturing the output from console
applications, etc. It's a Windows editor.
CUTE User-friendly
Text Editor
CUTE is a text editor that is extensible using Python. It
supports projects, syntax highlighting of various programming
languages (C, C++, C#, Java, Python, JavaScript) as well as HTML
(etc), multiple documents (tabbed or child frame), ctags,
auto-completion, search and replace with regular
expressions, bookmarks, undo/redo, has an integrated file
browser, themes, key macros, etc. Binaries (executables) are
available for Linux. The source code is released under the
GPL and can be compiled for Windows
Linux.com Some Linux apps are small wonders 13K in size for the editor
that's something from DOS era :-). It is written in NASM
assemblerThat's a great achivement and it refreshing to see that not all useful
software is bloatware !!!
e3 text editor
The e3 console text editor takes minimalism to
the max - the binary is a minuscule 13KB in size! So why use this instead of
[insert the name of your favorite editor here]? If you're anything like me,
you'll find a lot of your editing tasks are very short -- little more than
tweaks. e3 starts instantly and has all the basic features you could want,
including find/replace, block cut/copy/paste, and undo. For complex tasks I
use a more feature-packed program, but for a quick change to /etc/fstab or
something similar, this little editor wins every time.
e3 also does its best to be ubiquitous.
It works on a whole host of operating systems, and perhaps best of all, it
supports keyboard mappings that emulate WordStar, Pico, emacs, vi, and Nedit.
You can hardly fail to feel at home with it.
Exuberant Ctags Version 5.5.2 [17
September 2003]
[Sept 12, 2003]
The Right
Size for an Editor Eric Raymonds view on the subject. IMHO he did not
understand the real tradeoffs that make vi a great editor for so many years, but
he at least is able to site right people ;-). With all due respect to RMS,
Emacs is definitely anti-Unix type of editor :-).
Is Emacs an Argument
against the Unix Tradition?
The traditional Unix view of the world,
however, is so attached to minimalism that it isn't very good at
distinguishing between the adhocity-trap problems of vi and the optional
complexity of Emacs.
The
reason that vi and emacs never caught on among old-school Unix
programmers is that they are ugly.
This complaint may be “old Unix” speaking, but had it not been for
the singular taste of old Unix, “new Unix” would not exist.
--
Doug McIlroy
Attacks on Emacs by vi users — along with
attacks on vi by the hard-core old-school types still attached to ed — are
episodes in a larger argument, a contest between the exuberance of wealth and
the virtues of austerity. This argument correlates with the tension between
the old-school and new-school styles of Unix.
The “singular taste of old Unix” was partly a
consequence of poverty in exactly the same way that Japanese minimalism was —
one learns to do more with less most effectively when having more is not an
option. But Emacs (and new-school Unix, reinvented on powerful PCs and fast
networks) is a child of wealth.
As, in a
different way, was old-school Unix. Bell Labs had enough resources
so that Ken was not confined by demands to have a product yesterday.
Recall Pascal's apology for writing a long letter because he didn't
have enough time to write a short one.
--
Doug McIlroy
Ever since, Unix programmers have maintained a
tradition that exalts the elegant over the excessive.
The vastness of Emacs, on the other hand, did
not originate under Unix, but was invented by Richard M. Stallman
within a very different culture that flourished at the MIT Artificial
Intelligence Lab in the 1970s. The MIT AI lab was one of the wealthiest
corners of computer-science academia; people learned to treat computing
resources as cheap, anticipating an attitude that would not be viable
elsewhere until fifteen years later. Stallman was unconcerned with
minimalism; he sought the maximum power and scope for his code.
The central tension in the Unix tradition has
always been between doing more with less and doing more with more. It recurs
in a lot of different contexts, often as a struggle between designs that have
the quality of clean minimalism and others that choose expressive range and
power even at the cost of high complexity. For both sides, the arguments for
or against Emacs have exemplified this tension since it was first ported to
Unix in the early 1980s.
Programs that are both as useful and as large
as Emacs make Unix programmers uncomfortable precisely because they force us
to face the tension. They suggest that old-school Unix minimalism is valuable
as a discipline, but that we may have fallen into the error of dogmatism.
There are two ways Unix programmers can
address this problem. One is to deny that large is actually large. The other
is to develop a way of thinking about complexity that is not a dogma.
Our thought experiment with replacing Lisp and
the extension libraries gives us a new perspective on the oft-heard charge
that Emacs is bloated because its extension library is so large. Perhaps this
is as unfair as charging that /bin/sh is bloated because the
collection of all shellscripts on a system is large. Emacs could be
considered a virtual machine or framework around a collection of small, sharp
tools (the modes) that happen to be written in Lisp.
On this view, the main difference between the
shell and Emacs is that Unix distributors don't ship all the world's
shellscripts along with the shell. Objecting to Emacs because having a
general-purpose language in it feels like bloat is approximately as silly as
refusing to use shellscripts because shell has conditionals and for loops.
Just as one doesn't have to learn shell to use shellscripts, one doesn't have
to learn Lisp to use Emacs. If Emacs has a design problem, it's not so much
the Lisp interpreter (the framework part) as the fact that the mode library
is an untidy heap of historical accretions — but that's a source of
complexity users can ignore, because they won't be affected by what they
don't use.
This mode of argument is very comforting. It
can be applied to other tool-integration frameworks, such as the
(uncomfortably large) GNOME and KDE desktop projects. There is some force to
it. And yet, we should be suspicious of any ‘perspective’ that offers to
resolve all our doubts so neatly; it might be a rationalization, not a
rationale.
Therefore, let's avoid the possibility of
falling into denial and accept that Emacs is both useful and large — that it
is an argument against Unix
minimalism. What does our analysis of the kinds of complexity in it, and the
motives for it, suggest beyond that? And is there reason to believe that
those lessons generalize?
Recommended Links
In case of broken links
please try to use Google search. If you find the page please notify
us about new location
New
Moolenaar.net - Vim
Seven habits of effective text editing
the paper in
plain text (14 Kbyte).
the paper in
MS-Word (43 Kbyte).
the paper
in compressed PostScript (47 Kbyte).
the paper in
PDF (24 Kbyte).
the presentation
in Powerpoint (156 Kbyte).
the presentation
in compressed PostScript (228 Kbyte).
the presentation
in PDF (205 Kbyte).
See also
Softpanorama Society Orthodox
File Managers Site
Eastern Orthodox editors
Western Orthodox Editors
TCL-based editors
Lightweight Win32 Editors
Heavyweight Editors: alternatives
to the MS Word
Top
Open directory
Editors page -- all major editors are mentioned with current links to
each. Good starting page!
Vim Cookbook
DaveCentral
Programming - Text Editors, Page 1
Sinsite
-public-ftp-pub-Linux-apps-editors-terminal
Linux
Applications and Utilities Page - Programming
Freshmeat
Console-Editors
Freshmeat
X11-Editors
X-apps FAQ
II. X-based Editors
[July 15, 1999]
Ailanto Editing & Textprocessing -- very nice collection of links. The
author seems to be VI enthusiast. This collection has a lot more editors
listed, that on this Softpanorama page. Suggested by Tom Moran.
There is A
Perfect Editor by
Bruce Ediger
--- an good bibliography of research papers dealing with editor design,
usability, interface, etc. The author personally prefers Vim ;-)
Text Editor
Compendium (v2.07) -- by
Roger Nelson -- very interesting comparison tables.
program.htm -- Programmer features comparison table. He list several
features that are really important and thus the table can serve as a guide
for the selection of the editor
SAL --
Office Software - Text Editors -- (
Kachina
Technologies site) another collection of links. Each editor listed has
small annotation. I checked a couple and it looks like annotations are
correct and useful.
Tcl
Resource Center: software.applications.editor -- list of TCL-friendly
editors
PERL
Reference/Editors -- a very useful page -- contains information about
Perl enabled editors. Not much but better than nothing
Text Editors For Linux
QRG UNIX 10.Text
editors and browsers -- quick reference guide for linux
Ailanto: Editing &
Textprocessing
Goldshell is the
home of: DirSaver, FlashForga, Hoolicon, Pedit -- freeware DOS editor
OS/2
Warp on the 'Net, Software Developers, Utilities. -- some russian
developers
FreeBSD
Ports: Editors
GS31 Unix
Editors An Overview
X-apps FAQ II. X-based Editors
The
Programmers Vault - Programming Downloads
UNIX
Linux OS2 Dos Editors
exuberant ctags -- Darren Hiebert's page.
Ctags generates
an index (or tag) file of C language objects found in C source and
header files that allows these items to be quickly and easily located by a
text editor or other utility. A tag signifies a C language object
for which an index entry is available (or, alternatively, the index entry
created for that object).
Alternatively, ctags can generate a
cross reference file which lists, in human-readable form, information
about the various objects found in a set of C language files.
Tag index files are supported by the vi editor
and its
derivatives (such as vim, elvis,
stevie, xvi) through the use of the ":ta"
command, and by the emacs editor through the use of the "Meta-."
command, both of which locate the object associated with a name. There are
other a number of other editors which support tag files. A list of these
is found here.
Editors
- Popular Editors as on comp.editors --by
Sven Guckes Includes
small annotations and links to the foolowing editors: bingo, crisp, ee,
asyedit, fte, jed, medit, mined, nedit, qedit, slickedit ,THE
Design issues:
Interface Hall of Fame
MICO
The acronym MICO expands to MICO
Is CORBA. The intention of this project is to
provide a freely available and fully compliant
implementation of the CORBA 2.2
standard. MICO has become quite popular as an
OpenSource project and is widely
used for different purposes (see our success stories).
Our goal is to keep MICO compliant to the latest CORBA standard. The
sources of MICO are placed under the
GNU-copyright notice. The
following design principles guided the implementation of MICO:
start from scratch: only use what standard UNIX API
has to offer; don't rely on propietary or specialized libraries.
use C++ for the implementation.
only make use of widely available, non-proprietary
tools.
omit bells and whistles: only implement what is
required for a CORBA compliant implementation.
clear design even for implementation internals to
ensure extensibility.
Wishlist
for KDE 1.x2.0 main page
EMACSulation
LG #27 -- ediff capability
EMACSulation
Issue 26 -- emacs internet capability
EMACSulation
LG #25 -- transparent compress
EMACSulation
LG #39
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
****There
is A Perfect Editor Compiled by Bruce Ediger
"The comparison of widely
varying text editors
has only recently evolved beyond
subjective preference and name-calling."
- Nathaniel S. Borenstein, 1985
The "My editor is better than your editor"
argument easily comprises the longest-running
continuous argument in computer programming. One can easily dismiss most
of the common arguments on the topic, since the argument-makers appear
ill-informed, no definitions of terms ever get offered or agreed-upon,
hidden assumptions riddle the arguments and subjective preference carries
more weight than experiment. Nevertheless, editor users bring up important
points on ease-of-use, editing power, and what sort of interface an editor
possesses. Despite endless discussion, poorly-formed concepts like
"easy", "powerful",
"consistent" "intuitive"
and their opposites appear in most of the arguments. No two arguers agree
on what the terms mean.
In order to form more perfect arguments, I
present a first cut at a bibliography of real research that seems directed
toward finding the perfect editor. I did not perform an exhaustive
literature search, so please inform
me of any missing citations. I'm missing electronically-retrievable forms
for almost all of these papers.
*****
Anti-Mac -- an interesting critique of MAC-style graphic interface
***** Science
Fiction Writer Robert J. Sawyer WordStar A Writer's Word Processor
WordStar was first released in 1979, before there was any standardization
in computer keyboards. At that time, many keyboards lacked arrow keys for
cursor movement and special function keys for issuing commands. Some even
lacked such keys as Tab, Insert, Delete, Backspace, and Enter.
About all you could count on was having a standard QWERTY typewriter
layout of alphanumeric keys and a Control key. The Control key is a
specialized shift key. When depressed simultaneously with an alphabetic
key, it causes the keyboard to generate a specific command instruction,
rather than the letter. The control codes are named Ctrl-A through Ctrl-Z
(there are a few punctuation keys that can generate control codes, too).
Control codes are frequently indicated in text by preceding the letter
with a caret, like so: ^A.
WordStar's original designers, Seymour Rubenstein and Rob Barnaby,
selected five control codes to be prefixes for bringing up additional
menus of functions: ^O for On-screen functions; ^Q for Quick cursor
functions; ^P for Print functions; ^K for block and file functions; and ^J
for help.
Now, the first three of
these are alphabetically mnemonic. The last two, ^K and ^J, might at first
glance seem to be arbitrary choices. They aren't. Look at a typewriter
keyboard. You'll see that for a touch typist, the two strongest fingers of
the right hand rest over ^J and ^K on the home typing row. WordStar
recognizes that the most-often-used functions should be the easiest to
physically execute.
To
serve as arrow keys for moving the cursor up, left, right, or down,
WordStar adopted ^E, ^S, ^D, and ^X. Again, looking at a typewriter
keyboard makes the logic of this plain. These four keys are arranged in a
diamond under the left hand:
E
S D
X
Such positional, as opposed to alphabetic, mnemonics form a large part of
the WordStar interface. Additional cursor movement commands are clustered
around the E/S/D/X diamond:
W E R
A S D F
Z X C
^A
and ^F, on the home typing row, move the cursor left and right by words.
^W and ^Z, to the left of the cursor-up and cursor-down commands, scroll
the screen up and down by single lines. ^R and ^C, to the right of the
cursor-up and cursor-down commands, scroll the screen up and down a page
at a time (a "page" in the computer sense of a full screen of text).
^Q,
the aforementioned quick-cursor-movement menu prefix, extends the power of
this diamond. Just as ^E, ^S, ^D, ^X move the cursor up, left, right, and
down by single characters, ^QE, ^QS, ^QD, and ^QX move it all the way to
the top, left, right, or bottom of the screen. ^W scrolls up one line; ^QW
scrolls up continuously. ^Z scrolls down one line; ^QZ scrolls down
continuously. And since ^R and ^C take you to the top and bottom of the
screen, ^QR and ^QC take you to the top and bottom of the document. There
are many more ^Q commands, but I think you can see from this sampling that
there is an underlying logic to the WordStar interface, something sorely
lacking in many other programs -- particularly WordPerfect.
Now, for many of these functions there are dedicated keys on IBM PC
keyboards. WordStar allows you to use these, if you're so inclined. But
touch-typists find that using the WordStar control-key commands is much
more efficient, because they can be typed from the home row without
hunting for special keys elsewhere on the keyboard. Because of this, many
applications, including dBase, SuperCalc, SideKick, CompuServe's TAPCIS
and OzCis, Genie's Aladdin, Xtree Pro, and even Microsoft's own editor
included with MS-DOS 5.0 and above, have adopted some or all of the
WordStar interface.
Some keyboards have the Control key to the left of the letter A.
This makes using WordStar commands very simple. Other keyboards instead
have CapsLock next to the A and place the Control key below the
left Shift key, making WordStar commands a bit of a stretch. Because of
this, WordStar comes with a utility called SWITCH.COM to optionally swap
the functions of the CapsLock and Control keys. One of the problems with
other word-processing programs is that many commands can only easily be
issued through function and dedicated cursor keys, and the locations of
these keys changes radically from keyboard to keyboard (for instance,
function keys are sometimes arrayed as two columns of five on the
left-hand side of the keyboard and sometimes as a continuous row across
the top of the keyboard; cursor keys are sometimes clustered in a diamond
and sometimes laid out in an inverted-T shape; on laptop computers you may
have to press a special "Fn" key in combination with the arrow keys to
access PgUp and other functions, making using these programs an exercise
in contortion). But all one has to do to make any keyboard an
optimal WordStar keyboard is run the CapsLock / Control switcher, if
necessary. The locations of the other keys are irrelevant, because you
don't need them for WordStar.
On
the other hand, WordPerfect's interface forces touch typists to constantly
move their hands from the home typing row, slowing them down. To issue a
WordPerfect command, you must first press a function key, either
separately, or simultaneously with a Control, Shift, or Alt key. Then, for
many functions, you must select a sub-function. Now that your hands have
moved to the bank of function keys, can you select your sub-function using
them as well? You cannot. Rather, you must next reposition your hands to
the numeric keys and select your sub-function by number. Finally, you must
re-orient your hands on the home row before continuing typing (recent
versions of WordPerfect attempt to smooth out this tortuous interface, but
it's still difficult to use).
Linux Text Editors and A New One by Oleg L. Machulskiy
machulsk@shade.msu.ru
Conceptual Program Editors
Thomas W. Reps's Home Page -- Program Slicing, Differencing, Merging,
etc.
Word
Processing vs. Text Processing
What has
WYSIWYG done to us -- choose a version by by Conrad Taylor
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 <lang@tu-harburg.d400.de>
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
AE
documentation - Introduction
This editor was designed as a language configurable
folding
source code editor. A page describing the
concepts
involved is provided, and also a full list of all the
editing
primitives supported, with an
index
for speed.
This editor provides these features :
Folding, the ability to group lines into a larger 'meta-line'.
Block operations.
Yank and put model for line copying etc.
Deleted item stack to allow multiple undeletes.
Extended Regular Expression searching.
Multiple buffers at any one time.
Portability across many environments.
Bracket matching.
User configurable key binding.
Shelling out to and filtering through operating system commands.
The editor is relatively small for what it does.
PC-style super lightweight editors
mcedit and Cooledit
Jedit
(Java-based and not that super light)
FTE
LE
Jed
Joe
Dead Editors Society ;-)
FED
Zed
Other
In computer science, a good simple convenient text editor is a must. And most
of them have Windows heritage ;-) To this end, we've included a multitude of
Windows-style lightweight editors available today.
Cooledit
-- CoolEdit is part of a suite of
surprisingly easy and full featured apps. It is an excellent editor used by
Midnight Commander. It features multiple file editing, completely user
definable highlighting, keyboard commands etc. While it's not the prettiest
app, don't let appearances fool you, it is very capable. See also
What Is CoolEdit.
MCEdit --
FILENAME" It is actually a modified
version of CoolEdit. It is a very nice, very easy editor that offers a wide
variety of features, including context-sensitive highlighting, formatting,
search and replace, and more. If you're finding Emacs or vi to be a little
too much, give it a try.
gedit --
Part of the standard GNOME distriibution, gedit is a nice, simple fast editor
that is similar to Windows Notepad, but is extensible via plugins. In the
current version you can have open multiple files, and normal MS Windows
conventions (like CTRL-C CTRL-V) work. If you're new to Linux, check it out!
gnotepad+ -- Another GNOME Editor, gnotepad+
looks fairly simple, but has a lot of nice features. Again, it uses standard
Windows conventions, and offers unique items such as:
HTML tag help
Captures output from terminal
Open/edit multiple files
(Semi) WYSIWYG HTML Preview
Netscape preview of HTML Files
Multiple Windows
Search and replace (normal and Regex)
GXedit
Gedit
Kwrite --
The "Advanced Editor" standard on KDE
1.1.x, Kwrite is very similar to Windows editors such as Borland's editor, or
Arachnaphobia. It offers excellent highlighting for C/C++, JAVA, HTML, Perl,
and everything else I've tried. While not overly complex, this is a nice
editor for people making the transition from Windows to Unix. It is started
by Programs -> Editors -> Kwrite or "$ kwrite" on the command line.
GUI-based environments have some pretty decent PC-style editors
link KDE_KEdit and Nedit. For command line situation is not so good, but still
there are some decent implementations...
mcedit
MC also comes with what appears to be a much better editor known as mcedit.
this is a command line version of CoolEdit, but the development stalled long
ago.
This editor has interesting non standard for Windows cut and paste scheme.
First F3 marks start of selection, second F3 marks the end of selection and
highlight the selection. Then you can move your cursor. If you press F5,
selected area will be moved to the cursor location. If you press F6, selected
area will be copied and inserted to the cursor location. F2 will save file.F10
will get you out. Most other cursor keys works intuitively for Windows users
This editor can be directly started like:
$ mc -e filename_to_edit
$ mcedit filename_to_edit
This is not a multi-window editor but one can use multiple Linux console to
achieve same effect. To copy between windows, ALT-Fn-keys to switch virtual
consoles and use "File->Insert file" or "File->Copy to file" to move portion of
file to other files.
In Midnight Commander this internal editor can be replaced with any external
editor of choice.
Also many programs use environment variables EDITOR or VISUAL to decide which
editor to use. If you are uncomfortable with vim, set these to "mcedit" by in
~/.bashrc:
...
export EDITOR=mcedit
export VISUAL=mcedit
...
I do recommend to set these to vim if possible. Getting used to vi(m)
commands are right thing to do since they are always there in the Linux/Unix
world.
There is a very primitive man page (man mcedit). Here is one possible link
Manpage of mcedit;
here is slightly different
mcedit man page
for DOS port. In many Linux distributions mcedit comes with
completely brain-dead color scheme, but this can be easily fixed by defining the
following env. variable in your profile:
MC_COLOR_TABLE="$MC_COLOR_TABLE:editnormal=lightgray,black:editbold=yellow,black:editmarked=black,cyan"
The following options are defined in .mc.ini. You can modifiy them
to change the editor behaviour, by editing the file. Unless specified, a 1
sets the option to on, and a 0 sets it to off, as is usual.
use_internal_edit
This option is ignored when envoking mcedit.
editor_key_emulation
1 for Emacs keys, and 0 for normal Cooledit keys.
editor_tab_spacing
Interpret the tab character as being of this length. Default is 8. You
should avoid using other than 8 since most other editors and text viewers
assume a tab spacing of 8. Use editor_fake_half_tabs to simulate a
smaller tab spacing.
editor_fill_tabs_with_spaces
Never insert a tab space. Rather insert spaces (ascii 20h) to fill to
the desired tab size.
editor_return_does_auto_indent
Pressing return will tab across to match the indentation of the first
line above that has text on it.
editor_backspace_through_tabs
Make a single backspace delete all the space to the left margin if
there is no text between the cursor and the left margin.
editor_fake_half_tabs
This will emulate a half tab for those who want to program with a tab
spacing of 4, but do not want the tab size changed from 8 (so that the
code will be formatted the same when displayed by other programs). When
editing between text and the left margin, moving and tabbing will be as
though a tab space were 4, while actually using spaces and normal tabs for
an optimal fill. When editing anywhere else, a normal tab is inserted.
editor_option_save_mode
(0, 1 or 2.) The save mode (see the options menu also) allows you to
change the method of saving a file. Quick save (0) saves the file by
immediately, truncating the disk file to zero length (i.e. erasing it) and
the writing the editor contents to the file. This method is fast, but
dangerous, since a system error during a file save will leave the file
only partially written, possibly rendering the data irretrievable. When
saving, the safe save (1) option enables creation of a temporary file into
which the file contents are first written. In the event of an problem, the
original file is untouched. When the temporary file is successfully
written, it is renamed to the name of the original file, thus replacing
it. The safest method is create backups (2). Where a backup file is
created before any changes are made. You can specify your own backup file
extension in the dialog. Note that saving twice will replace your backup
as well as your original file.
jEdit
jEdit - Open Source programmer's
text editor -- if you use Java (1.4.2 or later, then it might be an optimal
choice, otherwise it might be too much staff to install ;-)
jEdit is a mature and well-designed programmer's text editor that has been
in development for over 5 years.
While jEdit beats many expensive development tools for features and ease
of use, it is released as free software with full source code, provided under
the terms of the GNU General
Public License.
The core of jEdit is primarily developed by
Slava Pestov, and jEdit plugins are
being written by a large and diverse team of programmers from around the
world.
Some of jEdit's features include:
Written in Java, so it runs on MacOS X, OS/2, Unix, VMS and Windows.
Built-in macro language; extensible plugin architecture. Dozens of
macros and plugins available.
Plugins can be downloaded and installed from within jEdit using the "plugin
manager" feature.
Auto indent, and syntax highlighting for more than 80 languages.
Supports a large number of character encodings including UTF8 and
Unicode.
Folding for selectively hiding regions of text.
Word wrap.
Highly configurable and customizable.
Every other feature, both basic and advanced, you would expect to find
in a text editor. See the
Features page
for a full list.
LE - le editor 1.9 by
Alexander V. Lukyanov - February 25th
2000, 12:37 EST. See also
ftp://ftp.yars.free.net/pub/software/unix/util/texteditors/
LE 1.9 supports Perl and has many block operations with stream and
rectangular blocks, can edit both unix and dos style files (LF/CRLF), is binary
clean, has hex mode, can edit files and mmap'pable devices in mmap shared mode
(only replace), has tunable syntax highlighting, tunable color scheme (can use
default colors), tunable key map. It is slightly similar to Norton Editor, but
has more features.
JED
The JED Programmer's Editor
-- a free text editor for Unix, VMS, MSDOS, OS/2, and MS Windows based on
S-Lang scripting language. Default
set of commands close to WordStar(or Borland IDE, if you wish ;-).
Actively developed and has active mailing list.
It is relatively small (less than 200K), loads fast, does not take much disk
space or memory. Included on most Linux distributions. For a
long tyme it is used as a standard editor on Slackware. On RH is it configured
to emulated Emacs mode (actually it's doing it pretty well and is noticeably
faster). To change to WordStar mode one needs to edit file
/usr/lib/jed/lib/jed.rc
and
commend out emacs related line()=evalfile("emacs");
uncomment the line ()=evalfile("wordstar");
Developed by John E. Davis, who also developed
S-Lang language. Embeddable
implementation of S-lang is often called S-lang library is pretty popular and
used in Midnight Commander and Lynx,
MOST, and
SLRN.
and participated in the development of
Color Lynx, rxvt.
slsc.
The color highlighting is a big plus. The latest version is B0.99-7 which may
be obtained via ftp from space.mit.edu which is also mirrored in Europe at
ftp://ftp.uni-stuttgart.de/pub/unix/misc/slang. Among features:
Color syntax highlighting on color terminals, e.g.,
Linux console or a remote color terminal via dialup (as well as Xjed).
Folding mode and selective display if jed is compiled
with line attribute support. To enable folding mode, you must set the
variable Fold_Mode_Ok to non-zero value in your jedrc file. See doc/fold.txt
for more information. `set_color ("...", "blue", "white");' may be used to
set the color of the "..." hidden line indicator.
Drop-down menus on _ALL_ terminals. Only from version
0.99
Emulation of Emacs, EDT, Wordstar, Borland, and and Brief editors.
Extensible in a language resembling C(S-Lang).
Completely customizable.
Capable of read GNU info files from within JED's info browser
A variety of programming modes (with syntax
highlighting) are available including C, C++, FORTRAN, TeX, HTML, SH, IDL,
DCL, NROFF...
Edit TeX files with AUC-TeX style editing (BiBTeX support too).
Asynchronous subprocess support. If asynchronous subprocess support is
enabled, jed will compile in the background.
Built-in support for the GPM mouse driver on Linux console.
Abbreviation mode and Dynamic abbreviation mode.
Bookmarks support(called for some reason line marks). See online
documentation `create_line_mark'. This is a bookmark that has a color
associated with it. A line that has a line mark will be displayed using this
color.
8 bit clean with mutekey support.
Rectangular cut/paste; regular expressions; incremental searches; search
replace across multiple files; multiple windows; multiple buffers; shell
modes; directory editor (dired); mail; rmail; ispell; and much, much more.
Mark Olesen's sendmail and mail-alias slang packages have been integrated
into jed. See sendmail.sl for more information.
There is also a useful add-on
jedstate. Using
jedstate together with jed's startup_hook() and exit_hook() as glue, jed
remembers the cursor position of all visited files and will automatically jump
to that position again when the files are revisited. The database, which is gdbm
based, is purgeable on a "time since last view" criterion. Jedstate comes with
two sample hooks for easy integration with jed.
Additional sources of information:
Documentation
JED, A Programmer's Editor
Another JED description
RPMs
charl's jed page --
Linux binaries and rpms
RPM of Group Applications-Editors
Debian GNU-Linux -- jed
Debian GNU-Linux -- jed-common
Online information on Jed and other programs from
Ohio State
University (Jan Hlavacek).
Online Jed information from
Florence, Italy
(Roberto Cecchini).
Online Jed information from
Vienna, Austria.
Some online documentation on
slrn, JED's
newsreader.
The
slrn FAQ.
FTE
FTE Text Editor (KFTE
-- KDE version) -- first written by Marco Macek, a Slovenian
computer-science student, who had been developing this powerful and configurable
editor for up to 1996 and then abandoned this project. It was practically dead
project from 1998 until Nov 2000, but then resurrected on Sorceforge. The latest
versions are a nice PC-style text editor with folding, undo, three types of
blocks, syntax highlighting (HTML, Perl, C, etc.). People interested in folding
can join the project.
SourceForge
Open Discussion
By:
Tanktalus ( Darin )
RE: Is this
really alive? [ reply ]
2000-Oct-13 15:10
I've tried to contact the developer a few times. When he
was back in school, I got responses fairly quickly. Nowadays, however,
nothing.
I've made a number of changes which make parts of it more usable - even fixed
a problem specific to AIX (where I use FTE alot!). I spent yesterday creating
the bmp's and icon so I could recompile it on OS/2. A few additions/fixes to
some of the configs ... all this stuff that could be used by others. Plus
OS/2 binaries with all changes...
<sigh>
By:
Tanktalus ( Darin )
RE: Is this
really alive? [ reply ]
2000-Oct-16 19:20
Well, it seems that CaptMark has given me developer access
- you may (or may not) have noticed that I've started adding things - mostly
bug fixes - into the code. New features ... come later. Bugs are easy to fix.
Just find the offending code and change it. Features require a deeper
understanding of the code. Maybe CaptMark will join in the fun later - or at
least let us know what he's up to.
(He gave me access without actually sending me email or anything.)
FTE- A
Folding Editor From the OS-2 World. FTE is a multi-platform editor,
available for Linux, OS/2, DOS, and Windows; support
Exuberant ctags. See a
short review of
an earlier version in issue 7 of LG.
Marco Macek, a Slovenian computer-science student, had been developing this
powerful and configurable editor for up to 1996 and then abandoned this project.
Main features:
Multilevel Undo/redo
Real best Dos-style textmode edit tradition with multilevel menus.
Multiple windows/multiple files editing.
Support linking of windows (the ability to edit file in several windows).
3 types of blocks (flexible operations on blocks and the ability to
select block until certain delimiters).
Cut and past in best DOS traditions (including a very rare in Unix world
ability to select block with Shift-arrow operation !)
No ability to process buffer with external commands (not yet)
There is also GUI-based implementation --
KFTE
-- a KDE port of FTE text editor. This version aims only at providing a
KDE GUI, and the core of the editor is unchanged.
Ftp sites for download
Latest source snapshot
fte-0.49.13.src.tar.gz
FTEN4913.ZIP
-- win32 binaries
OS/2 binaries are available
here.
Release 0.46b5
ftes46b5.zip - Source code
ftel46b5.tgz - Linux binaries
fteo46b5.zip - OS/2 binaries
ften46b5.zip - Win32 binaries
fted46b5.zip - DOS binaries (protected mode, DPMI required)
Joe
Joe editor -- The Joe editor has a set of command close to the WordStar, so
it can be convenient to DOS old-timers who know this ancient command set.
It was developed by Joseph H. Allen with assistance of Larry Foard and
Gary Gray. It is a full featured UNIX screen-editor. Included in RH. Also
available from ftp.std.com, file: src/editors/joe*.tar.Z. (ftp://nic.funet.fi/pub/unix/editors/joe2.8.tar.Z).
It is also able emulate PICO ('jpico' version), but who cares ;-).
Joe is lightweight (160K), text mode text editor and is not bad, but it's
definitely not my favorite -- I do not like Wordstar command set.
Key features:
Keybindings can be configured using joerc file, though.
Wordstar/Turbo-Pascal compatible block commands
primitive search/replace functions (no slicing)
It has (minimalistic) online-help (^ K H)
Can split the screen for editing multiple documents at once.
Can edit one file in several windows (link windoows feature)
You can envoke external program to act on the buffer content like in vi
(^ K /)
Only one buffer for cut and paste
hooks for automatically compiling files
rudimentary bookmarks
If ispell is installed, it can be run on a document with a keystroke.
joe is also quite configurable through its 'joerc' file. One can change
almost every aspect of joe through this file including: status bar, keybindings,
default behavior, help screen text and more. There are for example WordStar and
Emacs 'rc' files included with distribution of joe (see the /usr/lib/joe
directory).
To make it a default editor one needs to include in
/etc/profile the line
"export EDITOR=joe"
Additional information:
The
Joe Editor -- A Quick reference Guide to the Joe Editor
Norman
Matloff's Joe Editor Web Page
Joe
Editor Commands
Using the Joe
editor
Customizing the Joe editor
URM 207 - The Joe Text
Editor on Project Vincent
Edit with JOE Page
FED
[Nov 14, 2000] FED
- a folding text editor FED is a dead folding text editor
for MS-DOS and Linux, with source code freely available under the GPL. It
features:
fast and intuitive user interface
color syntax highlighting
can fold blocks of text out of sight, based on code
indentation
multiple levels of undo and redo
incremental 'as you type' searching
search/replace through multiple files
browse function to quickly find all references to a
symbol
automatic compiler error location
context-sensitive access to external help systems
flexible wordwrap, which correctly handles indented
blocks of text
block indent/unindent
binary and hex editing modes for hacking executable and
data files
record/playback keystroke macros
built in tetris game and screensaver
configuration options to alter key bindings, screen
colors, etc
DOS: fed.zip (262k)
Linux: fed.tar.gz
(200k)
ZED
ZED --
practically dead and should probably be removed. Was developed by
Sandro Serafini; has decent
DOS port. Default command set is WordStar like, but can easily be changed.
Current version seems to be 1.03 (as of July 1999). Does not make
much sense in view of existence of Jed.
Can use ANY keysequence (e.g. define a block with shift-arrow !)
even under unix local text terminal (linux).
intelligent screen update (NOT using the slow (n)curses).
Column blocks with insert & overwrite.
multi window/multi buffer.
color c++, html, tex, java, mail file.
shows parenthesis matching, searches for C functions, reindents C blocks.
about 200 commands and 100 variables to deal with.
Can edit/insert control codes (ascii 0-31 and 128-159).
executes programs with output redirected on a window (i.e. make, man,
etc...).
Can load files with CRLF and/or CR and/or LF end-of-line marker.
clipboard and delete buffer.
savable run-time macros.
simple and powerful configuration system.
easy document mode, almost ascii.
automatic wordwrap and reformat, even inside quoted line within a e-mail
file.
small, fast, powerful, low cpu consumer.
hexdump-like mode to edit binary file.
You can go everywhere with the cursor.
Internal, fast file selector.
Other GUI-based with ad-hos created macro
languages
NEdit the current
version is 5.1. C-like macro language. NEdit is now one of the most popular
editors in the Unix community. Version 5.1 is the first release of NEdit
under the GNU General Public License, and the first release to be done
entirely by volunteer effort. See also
APPWATCH.com Free Software - Open Source
"NEdit is a standard GUI (Graphical User Interface) style text editor for
programs and plain-text files. Users of Macintosh and MS Windows based text
editors should find NEdit a familiar and comfortable environment. NEdit
provides all of the standard menu, dialog, editing, and mouse support, as
well as all of the standard shortcuts to which the users of modern GUI based
environments are accustomed. For users of older style Unix editors, welcome
to the world of mouse-based editing!"
"The most significant enhancements in this release are:
New regular expression code, boosts highlighting performance by 40%,
and introduces many new and powerful features to regular expression
operations and syntax highlighting.
Incremental search, and optional search bar.
New ctags code with full support for Exuberant Ctags, better handling
of tag collisions, multiple tag file support, on-demand loading of tag
files, and automatic reload of modified tag files.
Optional display of line numbers along the left side of the text.
NEdit can now read and write MS DOS format files.
New built-in syntax highlighting patterns for Lex, PostScript, SQL,
and Matlab, and improved SGML/HTML and Java patterns. Many minor
improvements to other patterns.
Improved international character set input
New macro subroutines: list_dialog, getenv, set_language_mode.
Optional warnings about external modifications to files
Clearcase awareness
Session manager restart capability"
XEmacs A graphically enhanced
version of the Emacs (Lisp-like macro language).
xcoral
-- Text editor for X. Uses menus, key bindings and colors. A C-style
macrolanguage (SMAC -- SMall Ansi C interpreter). It has several modes to
edit C, C++, Java, Latex, HTML, Perl, Ada,C, C++, Java, Latex, Perl and more.
A multiwindows mouse-based text editor for the X Window System. A built-in
browser enables you to navigate through C functions, C++ classes, methods,
and files. The editor has a nice user interface and an extensive online
help system.
Crisp Editor
2.2e This is the public domain version which preceeded the current commercial
version. This is an updated version, which includes some bug fixes and a
working X version. Included in Caldera distribution.
Scriptum
- Slick programmer's editor with class browser
xwe, editor developed by Fred Kruse. Included into the Borland style IDE
xwpe.
Rather Strange Unix-based
Super-Lightweight Editors
pico-- a simple text-editing program created and maintained by the
Computing & Communications group at the University of Washington. Mapping of
commands to keystrokes does not resemble any DOS/Windows editor. The
basic features are text entry, searching, spelling checker, file browsing,
and paragraph justification. Very strange interface. I do not recommend using
it -- mcedit is much much better...
Pico
Tutorial
PICO 101 - An Introduction
to PICO Text Editing
nano -- a better version of pico
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."
Etc
Copyright © 1996-2008 by Dr. Nikolai Bezroukov.
www.softpanorama.org was
created as a service to the UN Sustainable Development Networking Programme (SDNP)
in the author free time.
Submit
comments This document is an industrial compilation designed and created
exclusively for educational use and is placed under the copyright of the
Open Content License(OPL).
Original materials copyright belong to respective owners. Quotes are made
for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on
this web page are those of the author and are not endorsed by, nor do they necessarily
reflect, the opinions of the author present and former employers, SDNP or any other
organization the author may be associated with. We do not warrant the correctness
of the information provided or its fitness for any purpose.
Last modified:
June 05, 2008
|
|
