trn

7 ms·

31.
by trn 5y ago
I have updated the documentation/README to provide background and rationale, and elaborated a bit on other comments. OpenBSD's vi (and OpenVi) differ distinctly from both Nvi ( https://repo.or.cz/nvi.git ) and Nvi2
32.
by trn 5y ago
For that level of UTF-8 editing, a non-mulitbyte version of the editor suffices. In fact, you can insert and modify multibyte signatures and names using the map facility, however the glyphs are not rendered on screen but are shown at the b
33.
by trn 5y ago
I plan to eventually support multibyte in a way I can contribute upstream to OpenBSD. The 1.8 branch of the Nvi editor, as well as the Nvi2 fork have mulitbyte support. I could be mistaken but I believe both of these multibyte implementatio
34.
by trn 5y ago
I have some comments here that address this, but, there are in fact many significant differences. The OpenBSD version forked at Nvi 1.79 around 1996-1997 and has been developed in the OpenBSD base system for 25 years now, and has diverged g
35.
by trn 5y ago
The behavior of the traditional vi is much different than vim and other clones. Nvi was a actually a re-implementation of the traditional vi for 4BSD (to be clean of AT&T code) and thus was originally intended to be bug-for-bug compati
36.
by trn 5y ago
Hi, I'm the "perpetrator" responsible for OpenVi. Apologies to everyone! /s I've added details to the README to hopefully explain why it exists: https://github.com/johnsonjh/OpenVi#why The Ope
37.
by trn 5y ago
This is something that I plan to tackle eventually, and in such as way the work can be contributed back to OpenBSD.
38.
by trn 5y ago
It isn't really an "old" version of Nvi by any means - the development went in a different direction. OpenBSD's vi has been developed mostly independently since being imported back in 1997. The documentation has been upd
39.
by trn 7y ago
I got it wrong too, when I answered a similar question, referencing rms' original speech. Unfortunately, his correction didn't seem to spread as far or as quickly as the original quote.
40.
by trn 7y ago
Also see https://lobste.rs/s/uwvpl1/110_days_early_multics_emacs_hist... if you'd like an easy way to use Multics Emacs.
41.
by trn 7y ago
Multics Emacs was the second Emacs to be implemented in Lisp, not the first. The first was Lisp Machine Emacs, known as EINE, (EINE Is Not Emacs) from 1977, while Multics Emacs is from 1978. (See also rms’ acknowledgement in the footnotes o
42.
by trn 7y ago
There is also https://ban.ai for a publicly accessible Multics system.
43.
by trn 7y ago
If you'd like to use Multics Emacs (with little effort) you can use the BAN.AI Public Access System - some relevant instructions are posted here: https://lobste.rs/s/uwvpl1/110_days_early_multics_emacs_hist...
44.
by trn 7y ago
For new install and first (cold) boot for a Multics system, the system is loaded from a Multics System Tape. As part of this process, the entire MST is loaded in Multics memory; Multics is partially started up to configure all of hardcore f
45.
by trn 7y ago
I made a post elsewhere earlier today to demo Multics Emacs, and just so happened to link to the very manual that rms refers to in that quote - the "Multics Emacs Extension Writer's Guide". https://lobste.rs/s
46.
by trn 7y ago
See https://en.wikipedia.org/wiki/Path_(computing)#Representatio... for a very incomplete list of examples. Also "." was extremely common, used on large DEC systems (RSX, VMS) and Tandem/NonStop as home
47.
by trn 8y ago
Multics, while not a 'massive' sales success in retrospect, was certainly not the failure commonly believed and wasn't treated as one in the press of the time - at least not until after the decision was made by Honeywell-Bu
48.
by trn 8y ago
Also see https://ban.ai/ and https://ban.ai/Multics/doc/
49.
by trn 8y ago
http://multicians.org/mepap.html - Greenberg's "Multics Emacs: The History, Design and Implementation" is the canonical Multics Emacs paper. While "emacs" is the command to invoke emacs, it was alwa