Why EDT?
The short answer is “Because I wanted it.”
The slightly longer answer is “I needed something of value to do while kicking the tires on CopperSpice. Adding themes and EDT keypad support to Diamond not only fit the bill but would benefit the world at large for as long as it could still compile.”
The much longer answer is the rest of this post.
I started out on the PDP 11/70 running RSTS/E. It was called a PDP because central buying policy by the US Government meant it was much more difficult to sell a “computer” than a “Programmable Data Processor”. Regrettably I can’t find an image on-line of the “RSTS/E is sexy” bumper sticker but I did find a scan of this history book covering Digital Equipment Corporation. Yes, an ancient machine, but as The Register reported in 2013, it will be running GE nuclear power plants to 2050.
I moved on to the VAX, then Alpha. As for editors, I used LSE (Language Sensitive Editor) when it was available, otherwise EDT. Both supported EDT keypad navigation. LSE just had a few more features. As long as we had terminals, it wasn’t a huge mental shift using a PC editor.
The terminal was in a different spot with a different keyboard and had a visibly different screen. The hardship started when we used terminal emulators. Don’t get me wrong. Reflections was and still is a fantabulous terminal emulator.
It was just that now I was using keypad navigation in one window and it didn’t work in the editor on the other screen. Many many many VMS developers were infuriated by this. PC coders couldn’t understand. They had never walked in the light. Emacs (and by extension Jed) did a pretty decent job if and only if you modified your terminal definition so they could successfully map the NumLock key; otherwise it was even more infuriating.
For more than a decade now I have been off in the medical device/embedded systems world. I’ve not much thought about it. Then came a few calls about VMS work while I was writing The Minimum You Need to Know About the Phallus of AGILE. That got me waxing nostalgic for COBOL and I started writing a book on GnuCOBOL. That lead to the discovery that every PC editor, even VSCodium, well and truly sucks at COBOL. Emacs was the closest thing to a “useable” COBOL editor out there. That lead to the writing (out early next year) of The Minimum You Need to Know About GUI Emacs. When I was testing GnuCOBOL I created an account on Eisner so I could compare it to DEC/COMPAQ/HP COBOL.
Had remapping the terminal so Emacs could find the NumLock key not been a violation of my religion, this particular journey might not have happened, at least for me. Someone would have made a similar journey. The OpenVMS operating system is being ported to x86_64 hardware. These old conversations are coming up again in comp.os.vms. Some people have made their peace with Emacs. Others are lamenting the lack of a modern EDT compatible editor.
We are talking about people with thirty to fifty plus years of software development under their belts. None of them would start writing an editor from scratch. Some of them would gladly pitch in once something got reasonably close. There are thousands of retired and semi-retired OpenVMS developers out there who are more than a bit bored during COVID-19. One has been bored enough that they are solving all of the C programming problems for some programming site using COBOL on a PDP for no other reason that to have something to do with a keyboard.
I wrote this for me but I hope to leave it for them.
When you have EDT emulation on and hit the [HELP] key you will get a big html written help screen in a browser window. The first image on it is this one. It then explains what is and isn’t implemented and how to use stuff. The real problem with the PC isn’t just the mentality of that universe, but the origins behind the keyboard.
Midrange and mainframe systems were purchased by businesses. During the 1960s through the mid 1980s much of the “work” done on these systems revolved around data entry. When the numeric keypad shown on the left side of the above image was designed it was designed by Efficiency Experts to reduce both strain and errors. We measured the efficiency of data entry screens by how often a user would have to move from “home row.”
Yes, even on character cell terminals we created drop down boxes for entry. A typist tabbed to the field and started typing. The displayed list would update with each keystroke showing only the entries that began with what they typed. When it got down to a single entry, it either auto selected that or there some something like [Return] they could hit to select it.
Today’s PC user interfaces throw efficiency out of a twelve story window in front of a fully loaded cement truck. They keep forcing the user to reach for the mouse. Combo boxes for many libraries/platforms don’t even allow a user to type in them. We are seeing some minor improvements in Web forms, at least when entering your state. When I type “i” for Illinois some actually scroll to the part of the list starting with “I” but far too many don’t.
Please take a moment and think about just how shitty the user interface is of your favorite editor when viewed for data entry efficiency. To select text you hit <Ctrl>-b or some key combination to “begin block” then you reach over to the arrow keys to navigate around, then you come back to home row to indicate “end of block” usually via some control key combination to copy or delete. “Oh, I use the mouse!” Well have a good long thought about that.
Movement from home row was always supposed to be an oddity or a limited event. That’s why when you look at old time data entry screens you see one of two things:
- All of the text fields on the left side of the screen and all of the numeric fields on the right. Entry proceeds down the left side then down the right.
- All text fields on the first screen and all numeric fields on the second screen.
When it came to inventory or other lookup type items that could not be just numbers, the letters used were always left handed letters, leaving the right hand over the keypad. The first person to suggest part number P1234 was fired.
Data entry needed a period, comma, and minus key for numeric values because not all forms formatted. The applications needed a few “special keys” so we got Programmable Function keys PF1 through PF4. EDT made use of those. The application told the terminal the keypad was in application mode and the terminal complied.
When PCs were “sold to business” they were initially sold to the accounting department. They were the only ones who could justify spending north of $5,000 to do spreadsheets. Spreadsheet users needed math keys. They basically needed a calculator keypad with a “Total” key they allowed someone to call “Enter.” There was great animosity between the PC world and the world of real computers. They absolutely refused to utilize the DEC keyboard despite it being the Unix standard. As a result you are missing a key. EDT users usually have to make some half-assed accommodation for this. The WORD key usually gets mapped as <ALT><KeyPad+> using the left <ALT> key.
Take a good look at the EDT keypad help again and consider selecting some text. (This is a shot of a Putty terminal actually logged into Eisner.) Forget about the left side, just look at the keypad. What are the steps to select text?
- First you have to navigate to the text you want.
- Start a selection.
- Navigate to end of text you want.
- Do something with the text.
EDT navigation was direction sensitive. It defaulted to ADVANCE but could be toggled between ADVANCE and BACKUP via the 4 and 5 keys on the keypad. Navigating a CHAR, LINE, Word, SECTion, or PAGE honored the current direction. Even EOL (End of Line) honored it as did DELete Line and UNDelete Line.
Prior to the PC, all of your navigation and basic editing was done with one hand. On the PC, if you wish to perform Word operations, you will need two hands, but the bulk of your operations are performed with one hand centered over the keypad.
If you needed text from various parts of various programs to be pasted into the program you are working on now, you simply opened those files up in other buffers and selected the text you needed. The APPEND would append your currently selected text to whatever was in the paste buffer (clipboard for you PC types.) Yes, I actually implemented that. If you want a rundown on the features I’ve been working on you can read it here. I had to add a clipboard viewer just so I could test this feature.
Once I have Diamond to where it is “good enough” I will expose it to my fellow EDT/VMS enthusiasts. At the very least there will be a few hundred who “give it a whirl.” These are all very seasoned developers. One or two joining the Diamond (assuming this code gets accepted) project would allow for serious enhancements. I can tell you right now some of the things that would be very high on their list of wants/priorities.
- Ability to support both ANSI-COBOL and DEC-COBOL-85. The current hard coding of comments in the syntax highlighting make this impossible. DEC-COBOL-85 was both free format and the comment indicator could be anywhere on the line. Haven’t dug deep into it for a while, but I seem to remember it also allowed for the “!” to be a comment-to-end-of-line indicator. ANSI-COBOL indicated a comment by having a “*” in column 7.
- FORTRAN-IV, 77, and 90 support. Again this spans the standards from fixed position card format to freeform coding. It also has an array of comment indicators.
- VAX BASIC. Still a rather large code base. Depending on the year written either had line numbers or did not. “REM” is the ANSI commend indicator. “!” was the DEC extension and it could be anywhere on the line. Hopefully they don’t want to deal with BASIC/PLUS from the PDP cross over era because that adds many parsing issues including “&” in column 78 (or 80) being a LINE CONTINUATION character.
- Bracket matching. I may actually get to this one on my own because I want it. Found some code that claims to do it, I just haven’t had time.
- Numeric constant highlighting. All of the regular expressions I have found don’t work when loaded from the syntax file. It’s something stupid and some other set of eyes will instantly see it.
I’m pretty sure you will see BLISS and a bunch of other languages pop up as well. Some of the people from VSI might contribute time (as if they have any spare time) as well. They would be the most in need at the moment as they are doing the OS port.
So, to sum it all up, myself and a bunch of others have suffered no end of frustration at the inefficient “standard” PC navigation. During these years when our hairs are turning either gray or white we want to see a modern editor with EDT navigation. I wanted to see it enough to do it. Like my brothers and sisters from that platform, I didn’t want to start from scratch.
Besides, the PC world needs to learn. Most of the shit they shun from the real computer world exists for a reason.
That’s why I added EDT keypad support. It’s not complete, but it is mostly there.
