My own way of using THE XEDIT

(see also my opinions in general and about text processing and text editors in particular.

It is a pleasure to have discovered THE, the Hessling editor by Mark Hessling, a powerful public domain emulator of XEDIT for Unix (and not only ...).
It's a long time since I ceased using the original XEDIT on IBM VM/CMS. Therefore, although I have a very pleasant recall of it being the best editor I used, I am not sure to remember correctly its look and feel.
And in the meanwhile I got used to other editors, like dxnotepad and pico. I also used other editors, of which I never liked vi, I sort of liked but hardly remember Wordstar, I remember a bit more but not much of VMS EDT and EVE.

In the past I used xc (a XEDIT clone by Patrick Hurley) for occasional use when I needed XEDIT features. However such s/w is no longer actively supported. I need now a robust, supported editor for serious everyday use, and therefore I will try to give to THE a mixture of all "best" features of the three editors, which I will describe below.

P.S. : the HTML manual of THE is here. (local copy for local use : for the official site (updated!) see here).

Screen Scrolling Insert/Delete Block operations Split view Colours Mouse operations Keys Misc Wishlist

Screen usage

Screen arrangement

The typical XEDIT screen is divided in 6 parts, the typical pico screen in 4 parts and the typical dxnotepad screen in 3 parts. I will list them, keeping together those which have a similar function, and discuss the arrangement I intend to use.

Screen movement and scrolling

The most obvious things one wants is to use the four arrow keys to move around in the file area. This is the most natural thing in any editor (apparently except vi :-)) and is the default behaviour.

However the XEDIT inheritance of the 327x terminals is such that when the cursor is at the top or bottom or the filearea there is no scroll, but one has to advance to the "next page" (or go back to the "previous page". Scrolling can be achieved from the command line with the UP and DOWN commands. I preserved this approach, and have multiple keys doing page advancement defined in my .therc profile (or defaulted) :

I would also like to mantain a scrollbar-like capability. Apparently somehow clicking with the mouse right button in the topmost or bottommost line of the prefix area achieves this. Otherwise I suppose I can lose the scrollbar habit and go back to the old (and more accurate way) of using XEDIT absolute line targets (:n from command line)

One more desirable thing for modern habits, is the usage of arrow keys to retrieve commands. This is easily achieved with SET CMDARROWS RETRIEVE in .therc. However I also keep the traditional IBM-ish (or was it a personal usage ? can't recall) of using a couple of numeric keypad PF keys for the same function, and another one for the "=" function of repeating the last command.
This has some interference with the usage of the enter key for inserting.

With the above redefinition of the arrow keys, I lose in part the capability of moving around the different screen parts. Only the capability of going from the filearea to the command line is affected. This can be recovered with the CURSOR HOME SAVE function assigned to a key, which for my traditions is NUM3 aka PF12.

Another problem concerns horizontal scrolling when the file is wider than the screen. This is not a standard behaviour in the various editors. I've setup my .therc profile so that :

Inserting and deleting

First of all, inserting and deleting what ? Let us consider a few cases.

Using multiple (split) screens

One useful feature of XEDIT (shared e.g. with editors like EVE) has always been the capability to edit multiple files at a time (the file ring) and to view more than one in separate portions of the screen. This is however nowadays of some importance only if one is editing at a terminal (which one does seldom, only when telnetting home), because otherwise one uses separate X11 windows.
However a nice feature of dxnotepad is instead the split screen facility by which one can have separate views of the same file in portions of the same window.

I'd wish to emulate such capability, subject to the restrictions of THE (which, unlike XEDIT and dxnotepad, supports no more than 2 split screens). The idea is the following :

All this is sort of implemented in my
splitscreen macro. Provisionally I have assigned it to control-\ (the backslash is a decent mnemonic for something which divides) at .therc profile level.

Using colours

Back in XEDIT time I'd never been too keen of colouring (mainly because we had only one 3279 colour terminal, perhaps :-) ). And that's not too unlike now, if I had to use THE as an editor in a standard terminal window (like the dxterm I normally use, or whatever I will get telnetting home) I won't have colour capabilities.

However I got used to a coloured background with the X11 editors I regularly use (starting with Sun's textedit and now with dxnotepad) ... mainly to have different aliases (edit1, edit2, edit3) to tell at a glance which file I'm editing looking at the colour of the window (e.g. cyan, yellow, etc. provided I remember which alias I used to start).

This is relatively easy to emulate with an alias like this
alias edit1 'xrdb -load edit1.x ; the -a edit1 \!*'
where the -a argument is used by the
.therc profile to invoke a macro arg(1) which does as a minimum the setting of the colour of the filearea, while the Xresource file is used to set things like the window size and the fonts used (I currently use a choice similar to my default dxnotepad arrangement).
In addition, since THE knows only a few fundamental colours (like black, cyan etc.) which are sometimes too bright, I also redefine my filearea background colour in the Xresource file (to mimic closely my dxnotepad colours), with a resource like :
the.colorCyan: #00fafa

These are example of 4 resource files ( 0, 1, 2, 3) and of the corresponding colour macros ( 0, 1, 2, 3)

The definition of the other colours is a matter of taste (I leave a black background for the other screen areas with a different choice for the foreground).

However a conflict can exist with the new THE facility of syntax colouring, which assumes for all its colours a black background. What one should do is either disable syntax colouring, or reset the background from black to the current value ... and of course avoid to have the same background and foreground. This should be dealt with by a macro. This is resetsyntaxcolor. At the same time I'd like a flag on the status line telling whether syntax colouring is on or off. This can be done at .therc profile level using STATOPT.

Cutting and pasting with the mouse

One would like to be able to use the mouse in several ways to select/mark blocks and act on them, consistenly with usual X11 usage. My own preference goes to a minimal use of mouse keys (i.e. I do not want to remember alt-shift-right-click things), ideally just two buttons plus accelerators.

I will therefore not consider the "exotic" default associations to mouse buttons provided by THE, but just note that :

This is instead the wishlist :

This can (sort of) be done at .therc profile level redefining some mouse actions but I am not convinced this will not make less handy the use of the mouse for normal operations, since there will be interferences between positioning clicks and selection clicks, and between blocks and X11 selections.
More innocuous is the addition of a definition to the control-W key to paste from the X11 clipboard (the mnemonic has been chosen for resemblance because control-V was already occupied).

Usage of keys

There are several bunches of keys available on a typical keyboard (besides the standard alphanumeric keys in the main keyboard) :

For what Control keys are concerned, the ideal association would be a mnemonic one, often dictated by compatibility with other editors. Thus my choice is :

An overview is reported in these maps.

Other features

In .therc I call at the end a macro recoverabort. which should look for the existence of an .aus file created by an aborted autosave, and ask the user if recovery in dxnotepad style is desired (replying yes will restore from the autosave file losing the current file content, and then saving it anyhow, which effectively also gets rid of the autosave file).



XEDIT had a nice full-screen, line oriented (sic!) file manager called FILELIST. Actually there were more than one, FLIST, FILELIST etc. and I do not remember much of them.
THE has a reduced way of running a file manager, when one invokes edit (or SOS EDIT) on a directory.

I am sort of thinking of a slightly more sophisticated thing doing something like this :

a XEDIT shell

To have a screen divided in 4 logical parts as a shell assistant.

Commands being typed are executed in the shell, their output is shown in the output area, while the command string is added to the history area (with a colour flagging if command was unsuccessful).
One could go to the prefix area, scroll the history area to locate a command, and :