SpendAllDayInTheEditor

HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences

One consideration is that a powerful text editor can become a desktop user interface. That is to say, the texteditor is the one and only interface into the operating system. GnuEmacs and XEDIT(on VM/CMS) are the two closest text editors I know that fulfill this promise. You can start up GnuEmacs and stay in it all day. Do everything from reading mail to compiling programs. And because you're in the text editor, everything can be copied and pasted everywhere else.

XEDIT is used a little differently. It is used to build program front-ends. The equivalent to 'ls' on unix for VM/CMS is written by pumping directory information into XEDIT and remapping keys around. Thus, you get FULIST on VM/CMS, FILELIST is also implemented this way.

MultiEdit and SlickEdit are two other PC editors that you can live in all day.

Interestingly enough, this is a great way to learn portable habits. That is to say, when you are spending the day in your editor, you are using keychords and commands that are the same regardless of the platform you are running on. Emacs is a great leveler in that respect. You just need to have Emacs on all platforms. ;-)

This is philosophically opposite from UnixToolsPhilosophy embodded in ed and ViFamily editors.

However, you might say that the OberonEditorFamily has a mix of both philosophies. It has the sparseness of the UnixToolsPhilosophy but the power of the EmacsFamily as an integrator of tools.


The concept of "Spending all day in the editor" goes *way* back. Users of IBM mainframes using 3270 terminals were familiar with it 30 years ago, as they probably spent most of their time in SPF (Structured Productivity Facilty), the full screen interface than ran on top of TSO (Time Sharing Option). SPF included an editor, and facilities for managing files, submitting jobs, printing, and doing other system tasks. Programmers could create custom panels to integrate into SPF to support arbitrary activity. Effectively, SPF was the user's shell.

As it was in the big iron, so it was in the small. The lowly Commodore 64 could be thought of the same way. The C64 used a one(!) mhz 6510 CPU, an 8 bit processor that could address 64K of memory. By default, 8K was mapped to a ROM chip that contained the kernel, the core OS routines, and another 8K was mapped to an early version of Microsoft BASIC in ROM. When you turned on the machine, you were in the BASIC interpreter, which became your shell, and you used the built-in editor in the interpreter to write BASIC code you could run. (The C64 had a full 64K or RAM as well as 16K of ROM, and assembly language coders could specify whether the machine saw RAM or ROM at the ROM addresses. This made it possible for clever programmers to stash code and data in "hidden" RAM "under" the ROM, flipping the ROM out of the way to access contents of the RAM beneath it. They just had to be careful their code didn't try to access kernel or BASIC routines while those ROMs were mapped out of the CPU address space.)

--DMcCunney


HomePage | RecentChanges | EditorIndex | TextEditorFamilies | Preferences
Edit text of this page | View other revisions
Last edited March 6, 2007 11:34 pm (diff)
Search: