> From this we can conclude that humans do not need any nice things like programming languages, assemblers or compilers to program effectively.
But maybe not efficiently. I realize that was tongue and cheek, but since this sometimes comes up in earnest (especially when it comes to dynamic vs. static type systems), it's worth noting that we knew from the very beginning that we can effectively program in what we'd now call adverse conditions: Not only were some earlier computers programmed directly in binary code (and Woz famously still programmed a 6502 by entering hex bytes into a monitor), before that we programmed by plugging in cords into panels, and in some sense still do in logic circuit design.
However, we sure became much more efficient in programming not only because higher level abstractions allow us to do things quicker, but because in addition of static type systems, we either catch really hard to debug issues much earlier, or won't make a lot of mistakes in the first place (you won't accidentally save a temporary into some register that you already used for something else even if it's "just C").
> especially when it comes to dynamic vs. static type systems
One nice thing about Typescript is that it gives us a mostly statically typed language and it has a control to compare against (JavaScript). That allows programmers to learn the strengths and weaknesses of both approaches. Previously most comparisons were apples versus oranges.
I'm guessing Python's Type hints (or Cython) also give a taste of the positives and negatives of static typing.
I would also presume both Typescript and Cython miss out on some of the more extreme optimisation benefits of static typing?
What's that weird APL derivative called that quants love so much? Julia? Reminds me a little of that, in the syntax at least. A little like MUMPS, too, maybe, and probably closer to that level in terms of its abstractions.
Beh. The first person said Julia (wrong). Then the reply assumed that parent meant J, but did not correct parent about Julia, leaving the misconception in place. Which I clarified.
No, I think they tried to correct them about that by saying "J is also up there" (implying "in contrast to Julia"), but I agree that that wasn't very clear, and that your clarification, even if it was under a wrong assumption, did help a lot. I stumbled across this as well.
I first learned to use TECO back in 1981 at Rose-Hulman, it was the OLD editor back then, but I thought it was interesting. I've always had some nostalgia associated with it. So much so, that I wrote my own clone for MS-DOS in Turbo Pascal back in 1989.... which is now usable in Windows 10, thanks to Free Pascal.[1]
I'm not sure if I've got things quite compatible enough to run all of those macros. I could run them in my Virtual VAX/VMS system, and see how they do on TECO32 there.
According to RFC 561 ("Standardizing Network Mail Headers ", 1973) it was literally "at":
We suggest that the text of network mail, whether transmitted
over the FTP telnet connection (via the MAIL command) or over a
separate data connection (with the MLFL command), be governed by
the syntax below:
Example:
From: White at SRI-ARC
Date: 24 JUL 1973 1527-PDT
Subject: Multi-Site Journal Meeting Announcement
NIC: 17996
At 10 AM Wednesday 25-JULY there will be a meeting
to discuss a Multi-Site Journal in the context of
the Utility. Y'all be here.
RFC 733 (Standard for the Format of ARPA Network Text Messages, 1977) has examples of addresses in both formats and this note: Whenever a message might be transmitted or migrate to a host on another network, full hierarchical addresses must be specified. These are indicated as a series of words, separated by at-sign or "at" indications.
"dd MON yy" is US military format, and I can see early computer scientists adopting it for its inherent unambiguity (and also extending it to yyyy for reasons that became obvious).
Americans colloquially prefer m/d/yy (slashes) rather than dashes, anyway.
Yeah. And we ultimately all quickly settled on the ISO-like format YYYY-MM-DD (with optional and varying delimiters, it does not have to be exactly ISO), which makes the most sense of all because you can just lexicographically sort it (e.g. when listing file names).
Wow, I know all those people on that recipient list!
Yes, “ at “ was still in use. ISTR typing ‘@‘ but this was a long time ago (I didn’t get to the AI lab until ‘78 by when EMACS was well entrenched).
This was pre TCP, pre RFC 733, pre DNS etc. I don’t remember if mail already had its own transport or if mail was still a special mode of the FTP protocol. I think that was still being argued over.
Any idea why there were @@'s in a lot of the messages? If you left @ as your TIP intercept character you had to type it twice, but only one @ would end up being sent. Those @@'s were in the email archive, and I can't remember ever seeing that before.
Speaking of intercept characters, did you know Will Crowther, one of the authors of Adventure, wrote the "Users Guide to the Terminal IMP"? You're in a maze of twisty little IMPs!
Don Woods, the other author of Adventure, is a great PostScript programmer! I worked with him at Sun on NeWS, but earlier he was DON@AI, so occasionally he'd get weird email intended for me.
> Any idea why there were @@'s in a lot of the messages? If you left @ as your TIP intercept character you had to type it twice, but only one @ would end up being sent.
I don’t remember either. Could be an artifact of all the file translation over the years, or even early cruddy OCR.
None of the folks in that list would have been using TIPs — ^R mode was added after KTVs were deployed.
mit-ai was running its, not unix, and there wasn't even a port of unix to the pdp-10 at the time. moreover uucp addresses are of the form host!user rather than user@host
To clarify on account of kragen's idiosyncratic avoidance of uppercase, "its" is "ITS", the Incompatible Timesharing System, developed by MIT's AI Lab:
yeah, eventually, but in 01976 uucp was just getting started. even in 01978 i don't think they had a well-defined network map, though they said uucp already connected over 100 unix machines in the 7th edition manual. that post is from 01981
unfortunately 'show original message' is grayed out, so i can't actually see the map
>The "ML Device" protocol is a remote file system invented for the PDP-10 MIT Incompatible Timesharing System. It may have been the very first transparent networking filesystem.
>Build:
Install libfuse-dev, then type make.
>Usage:
Create a mount point directory, and then mount an ITS file system like this:
>I know it's always hard to define an exact first, so I'll just ask about early network file systems. To be more specific, I'm wondering about file systems that transparently present directories and files as if they were local. I don't consider FTP or similar mechanisms to be candidates.
>For some time it has been my suspicion that the ITS "MLDEV" facility was very early ("the first"), but I never had any facts to back it up. I do have a file timestamped November 1972 that gives us an upper bound for the introduction of the facility. On the MIT-AI PDP-10, it provided an ML device (hence the name) which worked much like the local DSK device except the data was accessed through MIT's ARPANET IMP. MIT-ML of course had an AI device.
>Present evidence is that ITS had a very early networked file system no later than 1972.
>ITS has had a facility called the "ML Device", or MLDEV, for a long time. The name probably comes from a time when the users of the older more established computer called AI wanted access to files on the computer called ML. The "device" part is because ITS files are named by four parts: device, directory, and two file names. To access ML files from AI, the device name is ML. Conversely, from ML the AI device is used.
>To date this facility, we can check timestamps from backup tapes. The earliest file called MLDEV is from July 1975. However, if we examine the source code for an earlier ITS version we see that it has built in ML and AI devices that when accessed starts a program called SYS; ATSIGN OTHER. Disassembling this file we can see that it indeed is accepting file operations and sends information across ARPANET. The earliest file with that name has a timestamp from November 1972.
>We know from RFC documents 342, 344, and 366 that AI and ML were first put on the ARPANET in May-June 1972. So MLDEV could not have been in use before 1972.
The MLDEV was quite convenient for talking to the other ITS machines, as they just lived in the filesystem no differently from local files.
Among the many hackerish features of ITS was allowing a user space process to act like a device, not just for a filesystem but as a TTY, which allowed a lot more kinds of terminals to be supported than would fit in the monitor (kernel in today’s parlance).
> Among the many hackerish features of ITS was allowing a user space process to act like a device, not just for a filesystem but as a TTY, which allowed a lot more kinds of terminals to be supported than would fit in the monitor (kernel in today’s parlance).
I begin to understand where Plan 9 got that "other" kind of inspiration.
CRTSTY was kind of like "screen", in that it ran a virtual terminal through something like a pseudo TTY. The terminal interpreted SUPDUP protocol into any terminal type that CRTSTY supported. And you could disconnect and reattach to it later to restore your processes, to change terminals or survive a flakey modem or ARPA connection dropping out.
But even without CRTSTY, ITS gave everyone the ability to reattach to their processes after they got disconnected, and even pass processes like Lisp interpreters and Zork games around from user to user to share like a joint, by detatching and reattaching them to different TTYs!
>For display terminals which are not handled directly by the
system there exists a program called CRTSTY. This provides the software
support to permit these terminals to take advantage of their display
characteristics. Among the terminals supported by CRTSTY are: ADM3's,
Concept 100's, Hazeltine 1500's, Perkins Elmer FOX's, Datamedias,
Control Data Corporation 713's, and a host of others. You should try
:INFO CRTSTY and :INFO TERMS to see if your terminal is included. If it
isn't, the maintainers of CRTSTY are usually willing to help you add it.
In the CRTSTY section of INFO the information you must provide to have a
new terminal supported is listed. You can communicate with the
maintainers of CRTSTY by sending mail to BUG-CRTSTY.
>SUPDUP v. To communicate with another ARPAnet host using the SUPDUP
program, which is a SUPer-DUPer TELNET talking a special display
protocol used mostly in talking to ITS sites. Sometimes
abbreviated to SD.
>NWG/RFC# 734 MRC 07-OCT-77 08:46 41953 SUPDUP Display Protocol Page 1 Network Working Group Mark Crispin Request for Comments 734 SU-AI NIC 41953 7 October 1977
>SUPDUP Protocol
>This document describes the SUPDUP protocol, a highly efficient display telnet protocol. It originally started as a private protocol between the ITS systems at MIT to allow a user at any one of these systems to use one of the others as a display. At the current writing, SUPDUP user programs also exist for Data Disc and Datamedia displays at SU-AI and for Datamedias at SRI-KL. The author is not aware of any SUPDUP servers other than at the four MIT ITS sites.
>The advantage of the SUPDUP protocol over an individual terminal's protocol is that SUPDUP defines a "virtual" or "software" display terminal that implements relevant cursor motion operations. The protocol is not built on any particular display terminal but rather on the set of functions common to all display terminals; hence it is completely device- independent. In addition, the protocol also provides for terminals which cannot handle certain operations, such as line or character insert/delete. In fact, it is more than this. It provides for terminals which are missing any set of features, all the way down to model 33 Teletypes.
>The advantage over the TELNET protocol is that SUPDUP takes advantage of the full capabilities of display terminals, although it also has the ability to run printing terminals.
>The SUPDUP protocol [Crispin 77] is a highly efficient display telnet protocol. The advantage over the TELNET protocol is that SUPDUP takes advantage of the full capabilities of display terminals, although it also has the ability to run printing terminals. When you use the SUPDUP protocol, you do not need to tell the remote host which you are connecting to what type of terminal you have or what the terminal's capabilities are. The host you are SUPDUPing from handles the actual display support for your terminal.
>Additionally, SUPDUP defines a network graphics protpcol [Stallman 78] which makes it easy for network hosts to draw pictures along in addition to text.
You didn't need CRTSTY to implement the SUPDUP protocol, but CRTSTY translated SUPDUP to standard terminal escape sequences, and provided buffering and optimization. Lisp machines and Knight TVs had their own SUPDUP terminal programs, and I made one for my Apple ][ in Forth.
SUPDUP had a line saving extension that RMS hacked into ITS Emacs, so it can stash lines on the screen in local memory before overpainting them, then almost instantly pop them back on the screen later, so you can scroll back and forth through text really fast at 300 baud (plus Devon McCullough made ZipMod with Huffman encoding to make it even faster on top of that):
I wrote a terminal emulator for the Apple ][ + Videx 80 column card in FORTH and reverse polish notation 6502 code, that supported SUPDUP including the line saving protocol that RMS hacked into ITS and EMACS (%TDSAV %TDRES), so Emacs could stash lines on the screen in a memory buffer (on the Apple's bank switched RAM card) and restore them later to paint the screen quickly when scrolling back and forth. (That was great at 300 baud!)
This is just the part of it that interprets SUPDUP codes -- layered on top of the rest of the terminal emulator that emulated H19 (VT52 + character/line insert/delete):
At 300 baud over a congested ARPA connection, we had a lot of time to think about how to optimize terminal emulation while waiting for the screen to repaint...
When James Gosling later implemented his Unix version of Emacs, he created a super-hot screen update algorithm that automatically took into account the capabilities of terminals and the length of their escape codes and padding required (some slow terminals needed padding when performing line/character insert/delete operations, otherwise they would miss characters. It used dynamic programming to figure out the optimal way of updating the screen, which was really great at low baud rates like 300 or 1200 baud.
Read the paper and display.c code I linked to in the above linked comment, and see the wikipedia page on dynamic programming:
>James Gosling's Emacs screen redisplay algorithm also used similar "dynamic programming techniques" to compute the minimal cost path through a cost matrix of string edit operations (the costs depended i.e. on the number of characters to draw, length of the escape codes to insert/delete lines/characters, padding for slow terminals, etc).
The comments in this old PDP-10 SUPDUP code [5] are hilarious!
SUPDUP on ITS was so smart and opinionated, it had its own ideas about who was a loser and who was a winner, how to figure it out by checking INQUIR entries and relationships, and who it should never or always hassle about net-hopping (hopping through a PDP-10 over the net just to use it as a glorified terminal emulator).
It never hassled gumby or cstacy (because they were free to do whatever they wanted to, like flushing whiny annoying over-entitled alcoholic science fiction writers [1] [2] [3] [4]), but always hassled rms (because it was usually an imposter logging in as rms with password rms just to net hop through the system.)
[...]
;;; these people aren't hassled
wintab: irp x,,[gumby,alan,cstacy,cent,devon,dph,oaf,mly,jtw,jnc,klotz,cbf,sra,ed,swa,map,jbvb]
sixbit/x/
termin
winlen==.-wintab
;;; These people are always hassled
lostab: irp x,,[tk,hewitt,rms]
sixbit/x/
termin
loslen==.-lostab
Being able to attach and reattach consoles is cool. While I worked at Broadcom, I developed a kernel patch (whatever happened to it) which allowed you to have a stable serial console via a USB dongle.
I was able to unplug the USB-serial adapter from the embedded device's USB port. Then plug in a different USB-serial adapter (different chip requiring a different driver). It would obtain the same /dev/ttyUSB<n> device, and you would be back in your session intact. If you were in the middle of a vi edit, you could just Ctrl-L to refresh the screen and keep going.
SMTP evolved as replacement for older approaches which, at one point, involved using FTP to mangle mailboxes remotely. Not so much a special mode for FTP as essentially an "use of" FTP. Similar to how non-trivial amounts of Electronic Data Interchange in business happens over FTP(S) to this day.
UUCP was definitely not "Unix only", several operating systems supported it back in the day, Lisp Machines and ITS could access UUCP over Chaosnet. Mark Plotnick wrote the service (aka deamon) for Chaosnet for Unix in 1984.
For anyone who might not know, UUCP literally stands for "UNIX-to-UNIX copy".
Of course, especially given its relative simplicity, at some point non-UNIX systems started to implement it (I think I maybe used some DOS package at some point).
>> The reason the mail looks funny is that it predates the Internet;
some of what you see is Arpanet mail, and some (like the first one) is
internal ITS mail.
Two more curiosities:
- The sender’s address uses two at-signs, like NAME@@DOMAIN.
- There are typos where “at” is misspelled “ay”. Glad we don’t have to deal with that.
that syntax still worked with standard sendmail configurations in the 01990s; i wouldn't be surprised if sendmail still implements it by default today, though things like gmail, microsoft exchange, postfix, and exim presumably don't, and qmail definitely doesn't
I thought I remembered this from the 1990's, but kept seeing references to the 1970's. Before I had access to the Internet, I would sign into a local BBS and be able to write and receive emails using this syntax. Around midnight each day, the BBS would connect to the Internet and send and receive everyone's email for the day. I'd log on before school started to check my messages, and thought even back then how amazing the technology was. Now I see where we're at, and everyone takes for granted the near instantaneous sending and receiving of email and private messaging.
So you know how in school when you read that Constantine the Great became the Roman Emperor in the year 306. It was super confusing what was meant by the year 306 but if the book had 00306 you would have known right off what year they were talking about.
: dev3; cat longnow.c
#include <stdio.h>
int
main()
{
long then = 0;
long long now = 0;
long long long time = 0;
printf("then was %ld, now is %lld, time is %llld\n", then, now, time);
return 0;
}
: dev3; gcc longnow.c
longnow.c: In function ‘main’:
longnow.c:8:13: error: ‘long long long’ is too long for GCC
8 | long long long time = 0;
| ^~~~
So that when year 99999 ends, the Y100K bug can happen, I guess. No idea why having fixed-length 5- (or even 6-) digit strings for years is preferable to normal, variable-length decimal notation we use for numbers: 48, 112, 988, 1122, 2024, etc. The year is a number, treating it as a lexicographically-imbued string only matters for things like ISO 8601 (20240724T vs. 020240724T) but even then, it's already properly ordered: both "99991231T" and "099991231T" sort before "100000101T".
But hey, everybody has their small idiosyncratic pet peeves: I've ran twice into the same person here on HN who just can't stand term "x64" because it's "unofficial", but somehow refuses to use e.g. "EM64T" for it as well.
The Y100K Bug impacts every single financial transaction, every single transaction communication, and every single spread sheet, and table:
When it comes to this, the gods of Y100,000 will simply wish it with an act of will, and it will come about.
"Home was a couple of thousand light years away, which distance they traveled instantaneously, by an application of will. " -Joe Haldeman, "The Groombridge Effect"
>- The reason the mail looks funny is that it predates the Internet;
some of what you see is Arpanet mail, and some (like the first one) is
internal ITS mail.
Looking at https://datatracker.ietf.org/doc/html/rfc733 @ was already used behind the scenes in its current meaning, we're probably seeing a nicely human readable version of the emails sent.
Note I did not have the time to read the whole RFC and the above may be wrong.
When I started on the internet, in 1987, there were still !(band) addresses. Not for long, but... compuserve had their own format, uwasau.fi was connected to the US internet. GNU (GNU trix Ha!)( before HURD) was distributed by magtape. TLG, The little garden was my ISP.
On FreeBSD /usr/ports/editors/teco still works if you want to try your name and $ to see what awesome edit happens (my name starting with g I think means its g(lobally) applied)
Interesting to see '76 email formats had To: and CC: but not Subject: and Date: info was rolled into what now we might call the Envelope, projected into the header.
I used EMAS and Vax/VMS based email in '79 which was sufficiently second-system to have a standard to implement against and Type:Value was in, with Date: and Subject:
Also if anyone wants to dip your toes into teco, we're sufficiently full circle that there's an emacs implementation of it you can use! https://github.com/mtk/teco
I used to use meta-altmode (a non-ascii key on the KTV) to enter the minibuffer (note: not the region under the mode line) that accepted raw TECO and interpreted it directly.
And to be more extreme: you could actually write small assembly routines and run them in the registers (the first 20 addresses in the PDP-10 address space were the registers — super fast bc they were implemented with semiconductors rather than core!). That was hardcore and I only did it once or twice, just for fun.
I'd love to learn enough TECO to be able to do exactly that with Emacs's teco mode. I do it with ex (through viper) all the time. At this point I wonder if my brain has ossified to the point that it's incapable of learning a new language syntax.
It’s a bit trite to call out the next nesting step, but in this particular case I’d really like to see original TECO emacs running in modern emacs TECO.
My Pooh brain, especially today, goes into cognitive overload trying to keep track of an invisible point in a character based text editor.
Line editors are much less of a problem. In these I typically did not insert text in the middle of a line, I simply changed/substituted text in the middle of the line. This helps maintain context in contrast to moving a point around.
Fortunately, my TECO exposure was mostly tempered through VTedit, a screen oriented macro set for TECO on the PDP. Couldn’t escape it completely, but it helped reduce the load in my challenged, tiny brain.
By the time I moved to VMS, they had switched to EDT. Much more accessible.
At Waikato university a student, Ivan Piacun, wrote "vted", also a set of macros for TECO, on the PDP-11/70. I would say it was what most people used until the switch to VAX.
I tracked Ivan down on LinkedIn a few months ago. He says when he wrote "vted" he had absolutely no knowledge of other similar efforts, or of either emacs or vi, both of which existed (on the other side of the world) a couple of years earlier.
Everyone worked in a silo in those days.
You might eventually see something in BYTE (though it focussed on microcomputers) or Dr Dobbs (ditto) or Wireless World. Or something might make it ono a DECUS tape. But mostly you were just completely isolated if you lived on an island in the South Pacific Ocean, as we did.
I was happy with EDT, never got to like TPU's "Eve", though I didn't use it for long because I graduated ...
... graduated to a company that used DG MV10000 with AOS/VS, which had an even worse clone of TECO called SPEED.
There must have been a better editor, though I think still a line editor, but I have absolutely no memory of what it was called or how it worked!! I remember having to use SPEED for some things, but not most of the time. Maybe on very large files.
I was writing programs in PL/I and also Postscript on that machine. I hooked the brand new Apple Laserwriter to the MV10000, something both DG and the Apple dealer said was impossible, and used it, at first, mostly to replace an HP pen plotter to make diagrams and graphs to physically paste into gaps left in hard copy "camera ready" output from an IBM DisplayWriter word processing system.
EDT had rubber condom overlays for the Vt100 so you could know what numberpad key to use for magic edit, and the "gold" key which I thought was a superbad name for Meta.
I still have my cherished VT125 EDT rubber overlay from when I worked at DEC '82-'85. Great editor. And the amazing thing was that there could be 50 people time-sharing on a single 1 MIPS Vax 780, and EDT was very responsive, virtually no lag.
Yea, I walked into the SOS room day one of my degree and so learned SOS and Pascal instead of LISP and TECO. I do sometimes think I chose the wrong room. But your point about the point is well made, I think the DEC-10 TECO had a way to draw the current line and show where the point was, but it was very inferior to have to do it. Like chess wizards you're meant to carry an image of the code in your head at all times. I tried teco, couldn't entirely cope.
SOS led naturally to ed in due course. I did learn emacs, But never really took to it. Now, I run my daily work log in org mode and do nothing else in it, but it is very good as a massively over-engineered multi-window table editor.
Charles Forsyth (York) wrote a macro for ed which took the point, redrew the 24 line vt00 display to show the lines around it (12 above 11 below) and put you back where you were. He said it made ed as good as vi, and on the baudrate of the day who am I to disagree?
On the Cyber running NOS, we had XEDIT. And similar to your story, I routinely dumped 10 lines of context after each change. Whatever that command was, was hard coded into muscle memory to the point it was mostly automatic.
The other nice feature was that you could do quick in place edits from the command line. Combination of ed and sed.
Another aspect that impacted TECO on the PDP was the concept of paging the file in. The machine was limited enough that you as a user were responsible for swapping parts of the buffer in and out, which, while usable, was not a good user experience.
When loading a large file TECO/vtedit would prompt “loading file xxx.yyy slowly”. And it was. In the labs, my friend and I would commandeer multiple terminals, with one of them being our file loaded in the editor. We’d constantly write the file out, but never exit.
And by “large file”, I’m talking a 35K byte source file.
I'm nearly 60 years old. I used emacs in school and I still use it every day today. Along with the unix shells and utility commands, I can't think of any other software I've consistenty used for all those years. They really did it right with that stuff.
Back in those days, csh was more popular as an interactive shell. sh was used more for scripting. At least that's what I recall. bash didn't exist yet.
It's really remarkable just how durable the unix command line, emacs, vi have been.
From monochrome terminals to the latest (Android at least) phones you can still pull up a terminal and edit like it's 1984. Even on Windows with Cygwin.
If you had to bet on a technology still being there 40 years from now it would surely be that.
Wow! I'm putting together a podcast about emacs and I'd love to talk to you about your experience for it. Please contact jerod@changelog.com if you're interested.
multics emacs and lisp-machine emacs also predated gosmacs, which drew a lot of features from them, most notably being scripted in lisp (though gosmacs's lisp was a pathetic sort of thing called 'mocklisp')
Multics Emacs and the Lisp Machine EINE/ZWEI/ZMACS were also implemented in Lisp, they did not use an embedded scripting Lisp implementation. There is no boundary between an implementation and scriptling language, just one Lisp (Maclisp for Multics Emacs and Lisp Machine Lisp (aka ZetaLisp) for EINE/ZWEI/ZMACS), which in the case of the Lisp Machine also was used to implement the rest of the operating system and all its applications.
yes, and i should have said that, but gosmacs didn't copy that aspect of their design, just the ability to extend the editor in (mock) lisp
arguably gnu emacs is almost like multics emacs in this sense; the editing functionality of gnu emacs without any lisp code loaded is not actually zero but is pretty minimal. and i was surprised to find the other day that gnu emacs on my laptop is now compiling all my elisp to machine code, which is another similarity to maclisp, albeit a very recent one
For a similar situation today, there is the editor lem which is an Emacs-clone written in Common Lisp (and whose extension language is also Common Lisp).
more generally, though, even if you aren't using a gui library with a built-in text editor widget, gigahertz and gigaflops make it not especially challenging to write a usable text editor in a high-level language. http://canonical.org/~kragen/sw/dev3/edumb.py is 183 lines of fairly straightforward python and includes full-text search and infinite undo; it's not quite usable but pretty close. its really stupid buffer data structure might start to get unresponsive once you're editing a file in the neighborhood of 100k
Sadly, USB-HID does not define a hyper key, so no USB keyboard has a true hyper key. What one can do is configure the keyboard to emit a different, little-used key, and then configure X to recognize that key as hyper. I think what I do is emit left super for both super keys, and right super for both hyper keys, and then X turns right super into Hyper_L. Or something like that. This doesn’t bother me, because I don’t want to assign different meanings to the physical left and right super or left and right hyper keys — folks who do (e.g. for games) might not like it.
I also had to do a little bit of magic to get hyper recognised as a modifier.
It would be awesome if someone could get Hyper added to the official list of USB keyboard keys.
excellent! have you written up your configuration somewhere? are you using a public keyboard firmware?
at the other end of the spectrum, i just hacked together this stupid shell script to blindly reimpose my desired xkb configuration with lower-case parens yesterday: http://canonical.org/~kragen/sw/dev3/kbdd maybe you know the actually correct way to do this?
I actually own an original one (and some other goodies from my lispm time), I "just" need an adapter, but my electronics manufacturing / soldering talent is not adequate, sigh ;-0
If you're in the SF bay area, we might be able to get one put together... I've built several adapters for mice and keyboards, assuming the voltage levels are compatible it's mostly a matter of twiddling the right pins on a microcontroller. In return I would want to pick your brain about your lispm time :)
would it be a bad idea to rewrite the emacsLisp interpreter and other OS parts in a multi-core friendly language like preferably GO but rust would work too?
my reasoning is that it would add another 100 years to the shelf life of emacs. its good enough i dont have any reason to switch, but if the single threaded perf i s still a bottleneck in 5 years i'd probably switch to ZED.
http://pdp-10.trailing-edge.com/mit_emacs_170_teco_1220/01/e...
From this we can conclude that humans do not need any nice things like programming languages, assemblers or compilers to program effectively.