[HN Gopher] Understanding the Origins and the Evolution of Vi an...
___________________________________________________________________
Understanding the Origins and the Evolution of Vi and Vim
Author : amosjyng
Score : 266 points
Date : 2025-04-15 10:33 UTC (4 days ago)
(HTM) web link (pikuma.com)
(TXT) w3m dump (pikuma.com)
| ngcc_hk wrote:
| I was surprised to see this on pikuma... I guess " Also... Emacs
| sucks! " is ok to end the blog entry. To me it is just hard to
| use 2-3 figures and it seemed hard for inventory as well. That
| sucks.
| gustavopezzi wrote:
| Author here! I remember struggling with the decision of adding
| that last sentence or not. But at the end I was sure most
| readers would get that it is obviously a joke. Maybe a bad one
| but still a joke.
| herodoturtle wrote:
| I loved the ending! Glad you kept it in. I'm sure the emacs
| folks will appreciate the humour in it. And they're welcome
| to write their own article on the history of emacs and end it
| similarly. They've probably got a binding for it.
| neitsab wrote:
| I read it as sincere, gratuitous and unfounded mud-slinging,
| which made me end this remarkable article on a pretty
| underwhelming note. We all have different senses of humor,
| mine would have needed some caption here :'-)
| patrickdavey wrote:
| I was slightly surprised that they didn't add a mention of
| neovim.
| synergy20 wrote:
| while neovim is great and I intend to switch even, some time
| down the road, it caused a not-really-compatible fork and
| diverted the efforts, I wish them to be merged however hard it
| will be.
| kzrdude wrote:
| I am maybe just a year or so down from the switch from vim to
| neovim, but lua is a game changer. It's like, it's easy to
| configure stuff yourself now. Better plugins are written
| because the tools are better, or at least so I'm convinced.
|
| I will make a random comparison to latex vs typst
| (typesetting software). Both incorporate a programming
| environment, you can write a program right in your document.
| The difference is that the tex programming environment is a
| bit unapproachable and not very similar to other languages
| you may already know, while typst's equivalent is consistent
| and more similar to languages you know.
| sodapopcan wrote:
| Vim9script is actually a great language.
| kzrdude wrote:
| Well, I missed it because I seem to have departed Vim
| sodapopcan wrote:
| Ohhhh I misread, I thought you were saying you were a
| year away from switching, lol.
| behnamoh wrote:
| > ... lua is a game changer...
|
| Am I the only one who absolutely hates Lua? Its syntax, the
| fact that variables are global by default unless you local
| them, `foo = nil` isn't variable assignment but instead
| variable unassignment!, etc.
|
| There are far better scripting languages than Lua.
| kzrdude wrote:
| well, you could warm up to it by using vimscript first
| ykonstant wrote:
| vim9script is much more approachable while still being
| native to Vim's internals and idea of text editing. I
| don't know about using it for things like LSPs though,
| perhaps an expert could chime in.
| ajross wrote:
| You are absolutely not. In point of fact pretty much
| everyone hates Lua except the handful of folks
| integrating it. It has a huge lead in terms of
| embeddability and performance vs. competitors like
| Python. So you see it show up in little C applications[1]
| again and again and again because everything else is just
| too much of a hassle.
|
| But everyone agrees the programming experience in the
| language is awful.
|
| [1] My son just got into RC planes, so of course I found
| myself looking at ExpressLRS radios and pulling EdgeTX
| from GitHub. It's an otherwise straightforward ESP32
| board, and there in the app... yup, Lua everywhere.
| JSR_FDED wrote:
| > But everyone agrees the programming experience in the
| language is awful.
|
| Simply not true. The power to weight ratio of Lua is
| amazing. You can keep the entire language in your head
| easily, and even without LuaJIT it's crazy fast. It's
| great for creating DSLs. As a configuration language it
| is excellent- in fact that's how Lua originally came to
| exist.
| ajross wrote:
| DSLs and configuration languages aren't "programming
| experience" though. (Also that's oversold, you should be
| on a lisp if that's the design goal, Lua is a distant
| second.)
|
| I stand by what I said. Lua sucks for coding. The only
| people who like it are ones who haven't mastered one of
| the "real" environments.
| lawn wrote:
| It's true that Lua is very rough in many places.
|
| But it's still ten times better than Vimscript.
| tombert wrote:
| I've been playing with Rust a lot in the last few weeks,
| and I have been pretty happy with the Rust plugins
| available for NeoVim. It gives me most of the features I
| would want from a "real" IDE, but of course it's still Vim,
| so all my configs and other plugins still work.
|
| I'm convinced that the reason it's so good is because Lua
| is simply a better language than VimScript, making it
| easier to make plugins.
| sodapopcan wrote:
| If you follow any discussions around development, it seems
| the chance of this happening is essentially zero. I feel that
| they will continue to diverge into completely different
| editors.
| Buttons840 wrote:
| What do you predict the pros/cons of Vim vs Neovim will be?
| sodapopcan wrote:
| Hard to say, but as it stands, but my view is that that
| the typical nvim users want Vim as a full-fledged IDE
| with little effort whereas Vim users still want Vim
| largely as a text editor. And of course there are already
| a whole bunch of incompatible differences between them
| that would only be noticed by the more "power" users I
| suppose.
| layer8 wrote:
| It's mentioned in the "last 20 years" graph near the bottom.
| The article largely focuses on how Vim came to be, long before
| Neovim.
| rfmoz wrote:
| And vis editor, that also has herietage from sam.
| GregDavidson wrote:
| vis rocks!
|
| https://github.com/martanne/vis
| archargelod wrote:
| I actually use vis daily, alongside NeoVim - for opening very
| large files.
|
| Most editors choke at couple MB, Vis can open 10 Gigabyte
| text files with zero delay.
| jiehong wrote:
| Side note: that ADM-3A bears such a beautiful design. I like how
| its curves are akin to the screen curvature.
| dingaling wrote:
| A product of Lear-Siegler so it shares heritage with the
| Learjet family, through Bill Lear.
| PopAlongKid wrote:
| I bought a used one for my use at home while working on a
| university degree. And as another comment noted, vi would still
| be usable with a 300 baud (or 1200, I can't quite remember)
| modem. You could limit the visible "window" into your file to
| five lines on screen, so it didn't take so long to refresh.
| Alas, no longer have the ADM3a (but my kids when younger did
| use it as a play typewriter for a while).
| nickandbro wrote:
| Vim is awesome! For my hobby project, Vimgolf.ai , I am trying to
| make it easier and more fun to learn vim by being gradually
| introduced to the different motions. I am eventually trying to
| create different bots to create a standard of difficulty for each
| level but that is TBD at the moment.
| qsort wrote:
| It's incredible how good of a design Vi is. Try this experiment:
| Busybox includes a tiny clone of vi with a reduced feature set.
| It's very stripped down when compared to Vim or even other vi
| clones, but as a pure text editor it's _still more powerful than
| most modern day IDEs_.
|
| I love my Jetbrains IDEs, but you can take my Vim plugin from my
| cold dead hands :)
| pugworthy wrote:
| I have used VI for many, many years and honestly use perhaps
| 25% at best of its abilities. But still I get comments about
| how fast and smoothly I can use it from other developers. Which
| I think speaks to how powerful even the basic editor can be.
|
| And yes, you can also take my VIM plugin (for Visual Studio)
| from my cold dead hands.
| jxm262 wrote:
| Same here. Tbh, you're comment just inspired to do a deep
| dive on VI. Wonder how much more productivity I can squeeze
| out if I spend an weekend focused on it.
| skydhash wrote:
| The productivity comes from not having to think about your
| editing while simultaneously realizing that you can do some
| complex editing really easily. I use Emacs and Vim both (I
| prefer Emacs) and It's quite nice when you can streamline
| some quick code edits.
|
| My latest experience with Vim was helping a friend fixing
| some import with a React Native project. A quick grep on
| one terminal (I could have used quickfix) and using the vim
| fzf plugin to quickly locate the file. VS Code could have
| done this but the context switching and UI clutter is not
| great there.
|
| As for emacs, the main advantages lies in the fact that so
| many great tools already exist there. Things like Occur,
| Shell Mode and Compilation Mode (relying on Comint, a more
| general feature for anything REPL), Project, Eglot, and
| Magit.
| tcoff91 wrote:
| Now with neovim I feel like the plugin ecosystem is
| catching up to Emacs. Lua has unlocked the potential.
|
| Typescript dev ex in neovim is light years ahead of what
| I achieved in Emacs. Neovim's lsp integration is better
| than Emacs imo. Blink.cmp is so fast.
|
| Magit is definitely far superior to anything in neovim
| though and so is org mode.
| skydhash wrote:
| I think Vim and Neovim is better suited as editors,
| meaning quick launch, fast localization of files and fast
| editing actions. And I like plugins that support this
| philosophy.
|
| But the goals with emacs is to be a complete platform for
| anything plain text (with a bit of extra widgets). Almost
| whatever you need the terminal for can be replicated
| there, and they will share some common convention. Mail,
| file manager, music players, feed readers, PKM, PIM,...
| Tect editing is not so great, but text actions are (Slime
| is the best example).
|
| I use both, but I prefer emacs' extensibility.
| tcoff91 wrote:
| Yes Emacs is still a better platform for building
| applications on for sure. Emacs lisp is a better language
| than Lua although harder to learn.
|
| I used Emacs with evil mode for years until switching to
| neovim last year. It was really great.
| nyarlathotep_ wrote:
| > And yes, you can also take my VIM plugin (for Visual
| Studio) from my cold dead hands.
|
| First thing I install on any IDE/Editor.
| jghn wrote:
| It is worth knowing pure vi to some extent. To the point you
| raise, it's pretty much guaranteed to exist on any system
| you're on. That's not true of anything else, even vim
| maccard wrote:
| I can count on one hand the number of times I've had to use
| vi or nano and not had another option in 15 years
| programming. Optimising for that use case is not an efficient
| use of time.
| sudahtigabulan wrote:
| > It's incredible how good of a design Vi is.
|
| It's interesting how this design was forced into existence by
| the extremely limited hardware at the time:
|
| TFA>> It was really hard to do because you've got to remember
| that I was trying to make it usable over a 300 baud modem.
| That's also the reason you have all these funny commands. It
| just barely worked to use a screen editor over a modem.
|
| That's why we got commands like d), d{, D, etc. Trying to
| achieve the goal in one go, without any intermediate redraws.
| flomo wrote:
| That's a great point. On modern systems, there's a false
| economy where editor stunts are not going make most people a
| significantly faster programmer. (Although some ppl just like
| them, e.g thinking they are "more powerful".) But on a very
| slow terminal, these things really did make a huge
| difference.
| chongli wrote:
| For people who love vi/vim, it's not really about being "a
| significantly faster programmer." It's about reducing
| friction between the changes you want to happen and them
| happening on screen. Editors with a lot of friction (that
| make you do lots of intermediate or repetitive steps to
| accomplish a task) can be really annoying to use. For some
| people, minor annoyances can be very distracting to the
| point where they take you out of your comfort zone and
| break your concentration.
|
| Having your concentration broken when you're trying to
| solve a tricky problem can be a huge productivity drain. So
| in the end, an editor which may only save a keystroke here
| and there on average can end up being very productive for
| some people.
| flomo wrote:
| Absolutely, some people just love vi. Sometimes it fits
| their mental model, other times someone told them "real
| programmers use vim/emacs" and so they internalized and
| studied it. That's why most modern editors still have a
| vi mode. Obviously it works for people.
|
| But if the 1980s UI Scientists came back with their
| stopwatches, I don't think the median vi-mode user would
| "win". Unless they were using a really slow terminal.
| (obv, we probably have some 1%ers on HN)
| chongli wrote:
| That may be true because 1980s UI scientists were most
| concerned with building efficient and intuitive UIs for
| the vast majority of people, not for 1%ers.
|
| I know that I, personally, would not have been able to
| take some of the notes I took in university if it weren't
| for vim and its affordances. Trying to keep up with a
| fast-writing math professor while typing a complete set
| of notes in LaTeX would not have been possible otherwise!
| Izkata wrote:
| I don't think it's even so much about keystroke count as
| it is the "commands" are more like a language that you
| can keep getting better in. For example, from above:
|
| > d), d{
|
| That's not two different commands, it's one action
| (delete) and two different motions (forwards one
| sentence, backwards one paragraph). Motions work on their
| own for moving the cursor, but can be combined with
| different actions and repetitions to multiply the
| sentences (commands) you can make. As you increase your
| vocabulary over time (there are a _lot_ of motions and
| selectors (which are slightly different but used
| similarly)) you can keep reducing that friction between
| thought and screen.
| kryptiskt wrote:
| Yes, I'd say the composability of commands is vi's key
| feature. I can't remember any but the most common
| shortcuts in other editors. In vi I get so much more bang
| for the buck since I have easy access to all the commands
| I remember multiplied by the motions I remember.
| homebrewer wrote:
| And these commands are useless for programming unless you
| format source code in a very specific way, adding white
| space such that everything is split into "paragraphs"
| that can be thought of and operated on as a single unit.
|
| As someone down below mentioned, programming is not as
| much editing text as it is massaging the underlying AST.
| Proper IDEs (not VSCode) in a hands of a power user who
| knows what his "hammer" can do (and how to invoke the
| necessary behaviour) are much more efficient at it
| compared to any text editor.
| chongli wrote:
| _As someone down below mentioned, programming is not as
| much editing text as it is massaging the underlying AST.
| Proper IDEs (not VSCode) in a hands of a power user who
| knows what his "hammer" can do (and how to invoke the
| necessary behaviour) are much more efficient at it
| compared to any text editor._
|
| That's assuming you're spending all day editing files
| written in the language(s) supported by your IDE. That
| assumes a great deal about your programming environment,
| toolchain, plugins, and configuration. Switch to a
| different language with different syntax, different
| idiomatic style, different IDE plugins, and you may be
| faced with a totally different editing paradigm.
|
| This is where vi shines: the tool is excellent at editing
| text and is therefore 100% language-agnostic. It can
| easily handle jumping between files written in different
| languages, including plaintext files, configuration
| files, domain-specific language files, and otherwise many
| other files with syntax that may not be supported by your
| favourite IDE. Furthermore, it is equally happy working
| on files that combine different sections written in
| different languages. Sure, some other editors (such as
| emacs) and IDEs (such as RStudio) also support this sort
| of editing, but vi doesn't need any special support for
| it.
|
| This philosophy, of making text the first-class citizen,
| in many ways mirrors the Unix philosophy. It also happens
| to be the case that vi (as well as its ex command line)
| provides a very convenient command for piping lines,
| paragraphs, and any other motion you desire through a
| shell command (or pipeline) of your choosing. This makes
| it very easy to format text using commands such as `fmt`
| or `column`, or apply line-numbers using `nl`. This, I
| believe, makes vi the ideal text editor for developers
| working on Unix or Linux software.
| doix wrote:
| Yeah, vim was invaluable when I worked in the
| semiconductor industry. Lots of perl, TCL, SKILL (a lisp
| dialect) and giant verilog netlists. Languages which
| don't really have proper IDEs or great all in one
| tooling.
|
| Now I'm a webdev with everything written in typescript
| and just use Cursor (basically vscode) with the vim
| plugin. i miss the tab model from vim a lot, but apart
| from that the vim plugin is close enough.
| mikojan wrote:
| > As someone down below mentioned, programming is not as
| much editing text as it is massaging the underlying AST.
|
| Then why does your IDE not look like Scratch?
|
| It is because nobody has found a better representation
| then text when it comes to editing concrete syntax trees.
|
| Yes, you will rarely reach for d) or d} when editing Java
| or JavaScript. But the Vi paradigm does not stop at
| prose. And it does not stop at modern IDE capabilities
| either.
|
| The Vi paradigm just enables people to do it faster. With
| less friction.
| sudahtigabulan wrote:
| > I don't think it's even so much about keystroke count
| as it is the "commands" are more like a language
|
| It was about minimizing the number of redraws, but this
| indirectly might have led to fewer keystrokes too.
|
| As you mention later in your comment, there are a _lot_
| of motions (which could be combined with deletion too).
| This is probably related to performance too, because they
| make it possible to achieve something quite specific like
| c3), with only a single redraw, and three keystrokes.
|
| The "language" is undoubtedly a very good choice on part
| of Bill Joy. It wasn't necessitated by the hardware
| constraints, I believe. The separate modes neither. It's
| just that he would have wound up with less ergonomic key
| mappings.
|
| Without the modes we would have to suffer using chorded
| shortcuts with modifiers, but they could still form a
| language. Think "M-3 C-d C-)" instead of d3).
|
| Without neither modes nor composition (the "language"),
| it would have been even worse. A large number of single-
| purpose shortcuts, likely with multiple modifiers; he
| would have run out of (memorizable) single modifier
| combinations.
| davemp wrote:
| I'm not sure. Command based editing opens more doors than
| just optimizing keystrokes. There are edits I somewhat
| regularly do with Vim macros that save me minutes of typing
| and cognitive burden of examining refactor locations. It's
| probably not going to be make or break, but I do think it's
| significant in a p > 0.05 sense.
|
| I imagine Vim is only just a local optima too. There are
| newer editors [0] that are more AST aware that I haven't
| been able to fairly evaluate yet (not in the boring corp
| approved software list).
|
| [0]: https://helix-editor.com/
| alwillis wrote:
| > There are newer editors [0] that are more AST aware...
|
| With Neovim, you get the best of both worlds: it's Vim
| with AST support via Treesitter and LSP support baked in.
| arbitrandomuser wrote:
| This imo is a shortcoming of vim on modern systems, the
| action precedes the selection.
|
| I would like to select first have a visual feedback of what I
| selected before taking action on it . Helix and kakuone have
| got this right .
|
| I often find myself going to visual mode to emulate this.
| codesnik wrote:
| it's not "emulating", it's exactly what you describe. And
| it's just one additional "v" away, can't be shorter than
| that.
| Izkata wrote:
| It's the same for selections, but motions are a little
| different. To use an example from above, d) is "up to"
| the next sentence (excludes the first character of the
| next sentence), while v)d moves the cursor onto that
| first character and so includes it when deleting.
| teo_zero wrote:
| I don't think it's fair to talk about "shortcomings" and
| "getting it right": it's a different approach and we must
| agree that personal preference will diverge.
|
| Personally, I tend to use action-selection for small
| changes (1 to 3 objects), and selection-action for larger
| ones (as my brain, I've learned, becomes slower at counting
| above 3). So "delete 2 words" will be "2dw", but to delete
| the next 5 words I'll reach out for "v".
| tasuki wrote:
| > I often find myself going to visual mode to emulate this.
|
| It's just an extra key press. And you can choose which
| visual mode you'd like!
| eimrine wrote:
| > That's why we got commands like d), d{, D, etc. Trying to
| achieve the goal in one go, without any intermediate redraws.
|
| This is 1/2 of explaining why vi family is the GOAT. The
| remaining explanation is that vi family is the only text
| editor which is able to be used completely without looking at
| the keyboard or touching the mouse even once. You can not
| achieve this if you have to use accord commands which are
| typically binded to what is selected by mouse. No vim-less
| text editor can ever provide one-click analog of o command
| (make a new line under the cursor from wherever column the
| cursor is at the moment of clicking).
| nottorp wrote:
| That's the only reason I know some vi commands to be honest.
|
| It's unbeatable when editing files on a remote server in a
| hurry and from random places that may or may not have good
| latency and/or bandwidth.
| teo_zero wrote:
| >> It's incredible how good of a design Vi is. >It's
| interesting how this design was forced into existence by the
| extremely limited hardware at the time
|
| Can we learn that if you design something for a constrained
| environment, it will shine when the limitation is lifted?
| makeitdouble wrote:
| We're only seeing the rare examples that worked out well.
|
| For instance you don't want to code in assembly Facebook's
| backend. Blender would also be a completely different
| program if it was primarily optimized for the 68000. You
| usually will want different tradeoffs and architectural
| choices when the target platform drastically changes.
| thenthenthen wrote:
| What is the experiment?
| nikanj wrote:
| As a pure cutting tool, a traditional saw is more powerful than
| a chainsaw.
|
| That doesn't mean it's actually the fastest tool for the real
| job. Programming is not text editing
| _fat_santa wrote:
| I would say it's incredible to see the quality and "durability"
| of Linux/Unix tools. The other day I wondered "how old is
| grep", looked it up and realized that I use a piece of software
| that's over 50 years old on a daily basis.
|
| The fact that these tools have stood the extreme test of time
| is really something.
| agumonkey wrote:
| The history of ed, TECO and other pre live fullscreen programs is
| also worth reading.
| ggm wrote:
| Aside from neovim, no mention of nvi, Keith Bostic's fork which
| was BSD mainline, and the Japanese hacked on to add utf handling.
|
| The main divergence of note is tab expansion.
| bch wrote:
| And one probably wouldn't _notice_ , but the buffer is backed
| by a "recno"[0] Berkeley DB instance[1].
|
| [0]
| https://edoras.sdsu.edu/doc/BerkeleyDB/ref/am_conf/logrec.ht...
|
| [1] https://en.wikipedia.org/wiki/Berkeley_DB
| ggm wrote:
| Isn't that how most editors manage infinite undo/redo? I
| wondered if there is some magic "prune the backend and its
| now linear" model.
| montroser wrote:
| So interesting to see how the ADM-3A keyboard layout itself was
| such a fundamental influence for ESC and hjkl movement in vi.
| kps wrote:
| And that I suspect originates with ASCII Control-H = backspace
| (cursor left), Control-J = line feed (cursor down). Control-K
| and Control-L don't match but weren't so important that they
| couldn't be repurposed by an early display terminal.
| sudahtigabulan wrote:
| Yep. It's all in the manual.
|
| https://archive.org/details/ADM-3A-User-Reference-Manual-
| Apr...
|
| (This page, and Figure 1-3 below).
| anamax wrote:
| "while other editors, like Emacs, could cost hundreds of
| dollars."
|
| Huh?
|
| While I suppose that one "could" pay for Emacs, the vast majority
| of users never have.
|
| Then again, I've only been using Emacs for 45 years, so I'm a
| newbie. (Yes, I started with the Teco implementation.)
| halayli wrote:
| It's a bit dishonest imho to quote out of context. Here's the
| full quotation:
|
| > Joy also claims that most of vi's popularity came from the
| fact that it was readily available and bundled with BSD, while
| other editors, like Emacs, could cost hundreds of dollars.
|
| Joy was referring to the late 1970s early 80s here and in the
| context of making VI available when he created BSD and
| published it for free. Unix operating systems were not freely
| available outside academia back then.
| CalChris wrote:
| I've always considered TECO as the ur editor.
|
| Of course, TECO is the explicit ancestor of emacs, as emacs was
| originally implemented as TECO macros. However, I can't find a
| paper trail giving similar credit to TECO for vi. That said,
| istuff<esc> is the same in TECO as it is in vi and TECO (1963)
| well predated vi (1976). RSTS (along with TECO) was used at
| Berkeley in 1974 before v6 Unix was installed by Ken Thompson on
| a sabbatical to his alma mater in 1975. Bill Joy started as a
| grad student at Berkeley that same year. emacs (1976) wasn't
| ported to Unix until the 80s.
|
| There's no hard evidence and neither Ken Thompson nor Joy has
| ever mentioned TECO. So I'm probably wrong.
|
| But I still consider TECO to be the ur editor.
| ajross wrote:
| TECO was just a DEC line editor, not entirely unlike ed/ex. The
| idea of TECO managing a display terminal (i.e. the environment
| in which emacs was written as a bunch of macros) came much
| later, and really only existed at MIT.
|
| Glass TTY terminals were _very_ new in the early 70 's. TECO
| was primarily written to the "Knight TV" system, which was a
| fancy MMIO framebuffer array hooked up to a PDP-10 that would
| multiplex a bunch of displays and keyboards. There really was
| no "terminal" device per se, it was all software. There were
| other such devices (the MIT one was actually inspired by a
| similar system at Stanford), but nothing compatible enough to
| target an editor.
|
| So basically if you were at MIT you'd understand TECO as the
| pinnacle of editting . But no one else could use it.
|
| By the time Joy started writing vi, the idea of a "terminal"
| being a serial-connected device speaking a byte protocol with a
| handful of reasonable operations (position cursor, clear
| screen, etc...) had solidified. So a portable editor that would
| work with multiple devices was feasible. Emacs wouldn't get
| that for a few years yet.
| CalChris wrote:
| TECO was a _character_ -oriented editor. Also, it was widely
| available on RSTS, RSX, RT-11, ... and other DEC systems in
| the mid-70s. There's a character cursor. So if you opened a
| file with: The quick brown fox jumped over
| the lazy.
|
| The cursor would start before the T. 4C would position the
| cursor before the q. The 6D would delete quick . Then
| <esc><esc> would execute the command buffer.
|
| These fingers of mine learned TECO before they learned vi and
| then found vi easier to learn as a result. Besides the basic
| editing syntax, it was a programmable editor, hence the TECO
| emacs macros.
|
| Funny thing is that as fondly as I remember TECO, I've tried
| emacs a few times and have always worked my way back to
| vi/vim. I particularly like neovim now. I like using
| ex/command mode for doing bulk editing. Of course you can do
| the same thing in emacs but I've gotten used to it in vi. I
| remember programming TECO but I don't remember ever doing
| programmed editing.
| WalterBright wrote:
| I started with TECO (Text Editor Character Oriented) on
| Caltech's PDP-10 back in 1975. There were no glass ttys, just
| DECwriters and ASR-33s (ugh). I.e. TECO was a line editor.
|
| A couple years later, ADM-3A's arrived. And so did a TECO
| macro that turned TECO into a screen editor! Oh, what joy!
|
| Isn't it a amazing that a macro could turn a line editor into
| a screen editor?
|
| I also used TECO on my H-11 PDP-11 computer.
| WalterBright wrote:
| Here's that TECO macro (have fun!): [4 [5
| [6 [7 [8 [9 +0U7 0,0X4 10U4 [4 ETU4 [4 EDU4 [4 EUU4 [4
| ^D ET&(128#64#32#1^_)#512#16#8#2ET ED"G 0ED '
| @^U5/U9 ET#1ET 27^T Q9^T ET&(1^_)ET/ @^U6/.U8 ZU4
| -3U6 ^^HM5 13^T ^^KM5 10^T ^^KM5 13^T :G4 < ^TU7
| !F! Q7^T ZJ Q7@I%% Q7-10"E 13^T ^^KM5 -1%6 '
| Q7-21"E Q6^W 0U7 0; ' Q7-127"E -D Z-Q4"N -1AU9 -D
| Q9-27"E 32U9 ' Q9-31"G ^^DM5 ^^KM5 1+ ' 0"E
| 13^T -Q6-2< ^^KM5 ^^AM5 > 10^T 13^T :G4 Q4,ZT '
| ' ' Q7-27"E ^TU7 Q7-27"E !F0! 27@I%% Q4,ZX4 ^^HM5
| 13^T -1U7 0; ' Q7-^^?"E ^T^[ @O!F0! ' @O!F! '
| > Q4,ZK Q8J Q7/ 0,0X7 G_ ^YX8 ^YK 0,0X9
| ^^HM5 13^T ^^=M5 < !A! 0U4 0U6 !B! 1U5
| ET#32ET ^TU7 ET&(32^_)ET Q7"L -1^W ^TU7 ' !V!
| Q7-127"E .-Q5"L .U5 ' -Q5D @O!A! ' Q7-31"G Q7@I%%
| @O!A! ' Q7-26"E 0; ' Q7-21"E 0K @O!A! '
| Q7-11"E Q5K @O!A! ' Q7-8"E Q5L .-1"G 2R ' @O!A! '
| Q7-4"E Q5K @13I%% 10@I%% 2R @O!A! ' Q7-3"E 0; '
| Q7-27"N Q7@I%% @O!A! ' ^TU7 Q7-^^C"E
| Z-.-Q5"L Z-.U5 ' Q5C @O!A! ' Q7-^^D"E .-Q5"L .U5 '
| Q5R @O!A! ' Q7-^^?"E ^T&31#32U7 Q7-^^0"E
| Q5L @O!A! ' Q7-^^1"E Q5-1"E 0U5 ' Q5J @O!A! '
| Q7-^^2"E ZJ @O!A! ' Q7-^^3"E 0L @O!A! '
| Q7-^^4"E -Q5L @O!A! ' Q7-^^5"E Z-.-Q5"L Z-.U5 '
| Q5D @O!A! ' Q7-^^6"E @FR%% @O!A! '
| Q7-^^7"E Q5< 13@I%% 10@I%% 2R > @O!A! ' Q7-^^8"E
| Q5P @O!A! ' Q7-^^9"E Q5-1"E ^TU5 ' Q5@I%% @O!A! '
| Q7-045"E @^U4%Search: % M6"F @O!A! ' G4 ^Y-2X8 ^YK @O!S! '
| Q7-^^."E 0U6 !S! Q5:@S%^EQ8%^[ Q6"N Q6^W ' @O!A! '
| @O!A! ' Q7"D 0U5 < Q5*10+Q7-^^0U5 ^TU7
| Q7"D > ' @O!V! ' 0U8 Q7-^^A"E -1U8 '
| Q7-^^B"E 1U8 ' Q8"N Q5*Q8U5 Q6"E 0U7 .U8 0L
| Q8-.%6< 0A-32"L 0A-27"N 0A-9"E 6-(Q7&7)%6^[ -2U7 ' %7 1%6 '
| ' C %7 > ' Q5L -Q6U9 0U7 Q6< .-Z; 0A-32"L 0A-13"E
| 0; ' 0A-27"N 0A-9"E 6-(Q7&7)%9^[ -2U7 ' %7 1%9 '
| ' C %7 1%9"G R ' Q9; > 0U4 @O!B! '
| Q7-^^Q"E @^U4%Command: % M6"F @O!A! ' G4 ^YX9 ^YK @O!C! '
| Q7-27"E 0U6 !C! ]4 Q4EU ]4 Q4ED ]4 Q4ET ]4 Q4-10"N ^O ' M9
| 10U4 [4 ETU4 [4 EDU4 [4 EUU4 [4 ^D
| ET&(128#64#32#1^_)#512#16#8#2ET ED"G 0ED ' -1EU
| Q6"N Q6^W ' @O!A! ' Q7-^^R"E G7 @O!A! '
| Q7-^^P"E Q4"E .+1U4 ' Q5L Q4-1,.X7 Q4-1,.K G7 0U6 @O!B! '
| > ET#16ET ^^>M5 ^^YM5 23+32^T 0+32^T ^^KM5 13^T
| !Z! ]4 Q4EU ]4 Q4ED ]4 Q4ET ]4 Q4-10"N ^O ' ]9 ]8 ]7 ]6 ]5
| ]4
|
| Obviously, the TECO programming language was a challenge to
| understand. Mitigating this is it needed to be extremely
| compact, as it was used on a 64Kb PDP-11.
| userbinator wrote:
| That has a texture reminiscent of the J/k family.
| WalterBright wrote:
| At the time, I was told that a student once claimed that
| TECO was a complete programming language. He was challenged
| to write a FORTRAN compiler in TECO, and did.
|
| I'm not sure if that was true.
| iDon wrote:
| The name I recall from using it on a PDP 11/04 was 'Text
| Editor and Corrector'
| https://en.wikipedia.org/wiki/TECO_(text_editor)
|
| I vaguely recall it had a line-open / visual mode, like
| ex/vi, which we didn't use because we were on a dot-matrix
| line printer / teletype. The ADM-3A had the Ctrl key on the
| home line; this design made it easy for editors from that
| period (vi, emacs) to make heavy use of Ctrl.
|
| Thanks to those who posted bits of TECO - I'd forgotten how
| the character movement was similar to vi. A fellow student
| in our CS honours year had a semester thesis project
| analysing the grammar of vi commands and specifying it in a
| formal grammar. The combination of action x movement is
| powerful, simple and concise.
| SulphurCrested wrote:
| It could also be invoked on VAX/VMS under the name
| "MUNG", which was said to stand for "Modify Until No
| Good". I think that style of invocation did something
| slightly different than using the TECO command, like
| creating a new file.
| SulphurCrested wrote:
| We had TECO on our DEC VAXes running VMS in the early-mid
| 1980s. It had a "VT52" mode (as you say, a macro), and at
| least one of the terminals on my desk supported those
| escape sequences. Wikipedia says the VT52 terminal was made
| from 1975 to 1978, so those macros were probably fairly
| early. By this stage, TECO distribution was fragmented with
| various incompatible versions around, so probably some
| lacked that macro or other full-screen macros.
|
| Although I had a terminal which could run TECO full screen,
| I found that too slow and just used it in line mode. You
| could conveniently reprint surrounding lines by adding a
| few characters to the end of a commmand (I still have HT
| <ESC> <ESC> burned into my brain.) The VT52 macro had you
| typing commands into line 24 like an emacs minibuffer.
|
| I never used it for all my editing, but it excelled at
| certain things.
|
| The version of TECO we had was the one which shipped with
| VMS. At some point later on, I think, DEC stopped shipping
| it, and we migrated to a TECO-inspired full-screen editor
| developed by another university. Once that arrived, we
| hard-core TECO users, all 4 of us, were won over within a
| week.
| WalterBright wrote:
| Great story!
|
| The TECO macro I posted is the VT52 one.
| beezle wrote:
| A lot of the "elite" compsci students at my college in
| the early-ish 80s were still using TECO on our DECSYSTEM
| 2060 but some of the cool-kids were trying that new Emacs
| thing ;)
|
| Me, being just a lowly compsci minor, prefered the full
| screen editor called FOXE. Was very simply to use and did
| the job fine for writing/editing programs of the length
| typical of homework assignments. Don't recall all the
| particulars to comment on search, replace, etc.
|
| Unfortunately, there is like zero internet info on it
| beyond: "Little (if any) information is available for
| this visual editor available for TOPS-20 in the early
| 1980's. It was similar in appearance to the then new
| EMACS but had a far simpler command structure."
| ChuckMcM wrote:
| I was a TECO user on RSX-11M, then switched to FINE (Fine Is
| Not EMACS :-)) on Top 10 & 20. When I started at Sun I
| started using vi but on the Amiga I continued to use
| MicroEMACS which felt a bit like FINE[1]. After Sun I pretty
| much stuck to vi because it was so much faster over a remote
| X11 connection than EMACS was.
|
| Also used PFE32 for a while on the Amiga, sad that the source
| for that never made it out.
|
| [1] I still have Craig Finseth's thesis "A Cookbook for an
| Emacs" which talks about designing FINE.
| fuzztester wrote:
| >Also used PFE32 for a while on the Amiga, sad that the
| source for that never made it out.
|
| I also used PFE32 (on Windows), and for those who may not
| know, the acronym stood for Programmers File Editor, IIRC
| :), and the 32-bit version, probably. It was a nice
| lightweight text editor. One feature it had, that not many
| other editors might have had at the time, was the ability
| to open fairly large text files (for that time, at least).
| drbig wrote:
| Reminded me of CygnusED, which apparently has even a working
| website[1]. I really wish the core idea of ARexx had become
| popular enough.
|
| 1: http://www.cygnused.de/index-en.php
| teo_zero wrote:
| There was another editor for the Amiga, possibly only known to
| the users of Matt Dillon's DICE compiler, that integrated so
| well with ARexx that at a certain time I suspect ARexx code
| surpassed the core C code. The name's DME and the source is
| still available.
|
| I can't agree more on the beauty of a OS-endorsed scripting
| language embeddable in every application! Lua might take that
| role one day...
| YesThatTom2 wrote:
| CygnusED's speed made it feel unlike any other editor.
| Brilliant engineering!
| jasperry wrote:
| Bram's first version of vim was for the Amiga! Indeed, as the
| article says, this deserves to be more widely known.
|
| On the other hand, an Emacs clone (MicroEmacs) actually came with
| my Amiga 500's bundled extras disk...
| bodyfour wrote:
| > The creator of MINIX, Andrew Tanenbaum, asked the community to
| choose between Stevie and Elvis to be adopted as the main text
| editor for their OS. Elvis was chosen and it's the default text
| editor on MINIX until today.
|
| Point of order: Minix switched to BSD nvi in 2013
| https://github.com/Stichting-MINIX-Research-Foundation/minix...
|
| Not that it matters -- Minix itself hasn't had a commit since
| 2018 -- but the last five years of its life were spent without
| Elvis
| litoE wrote:
| Up to now I have been using elvis exclusively, rather than vim,
| both on Windows and Linux - I never saw the need to switch,
| since elvis does everything I need. I just retired it last
| month, when I upgraded some systems to the latest release of
| Debian Bookworm and the elvis graphic interface started
| crashing the whole X windows manager. I have the source code,
| but I don't have the patience to recompile and debug it.
| ilrwbwrkhv wrote:
| As a slight aside if you want unabashed joy for 18 hours, take
| Pikuma's Raycasting Engine Programming course. One of the best
| courses I have taken and I don't do many courses because I have
| stuff to do. Also it's in C.
| kjellsbells wrote:
| Retrocomputing spelunkers might also look at EDLIN, a line editor
| that shipped with MS-DOS that had a great deal of similarity to
| UNIX ed.
| Narishma wrote:
| I think EDLIN is closer to CP/M's ED.
| Animats wrote:
| The ancestor of all those full screen terminal editors is the
| RAND editor, which was on Unix around 1974.[1] Few people outside
| the DoD research community saw it, because it wasn't free and
| only worked on some terminals. Functions were triggered by
| dedicated function keys, not key combos or a command line, and it
| was customary to use something with 8 to 10 function keys, such
| as the HP2645A. You could split the screen, edit two files, and
| do cut and paste. Way ahead of its time.
|
| [1]
| https://www.rand.org/content/dam/rand/pubs/reports/2008/R217...
|
| [2] https://terminals-wiki.org/wiki/index.php/HP_2645A
| bakul wrote:
| I used the rand editor in early 80s & loved its "infinite"
| quarter plane model. Dave Yost enhanced it quite a bit and
| called it the Grand editor. But it was hard to maintain as it
| relied on K&R C. Eventually I gave up and went back to vi.
| asicsp wrote:
| See also: "Where Vim Came From"
| https://twobithistory.org/2018/08/05/where-vim-came-from.htm...
|
| Discussion: https://news.ycombinator.com/item?id=17696023 _(420
| points | Aug 6, 2018 | 259 comments)_
| notorandit wrote:
| My first text editor has been vi on NCR Unix machines back in
| 1986 and DEC Ultrix in 1988. I fell so deeply in love that I
| joyed only when I could get a "copy" of vi.exe from MKS unix-like
| toolkit for DOS. That file only.
|
| Nice read, indeed. Especially the final sentence.
|
| > Also... Emacs sucks!
| bsdz wrote:
| In a, thankfully past, role working remotely for an antipodal
| organisation with badly configured networking; often, the lag
| between typing several characters on the keyboard and those
| characters appearing on my screen could be measured in seconds!
| Vi key bindings were a godsend as I could send commands (eg
| global search & edit etc) and be confident they were being
| applied before recieving a (delayed) visual update. I feel my
| experience seems to echo (albeit slightly) that of Bill Joy's vi
| development on a 300 baud modem!
| sunshine-o wrote:
| vi and the UNIX shell are just beautiful tools.
|
| It always amaze me that I was only introduced to them in my adult
| life way after Windows, but still for me they are the definition
| of what computer is.
|
| So this is not really about (personal) nostalgia.
|
| Also in the age of 8K screens, VR, AI and AI ready computers, a
| lot of people still use and love vi.
|
| Call me crazy but my guess is there might still be vi users in 50
| years.
| bsenftner wrote:
| Harvard University used to teach an assembly language class back
| in the 80's, taught on a mainframe - a VAX 11/780 or similar I
| seem to recall. This was an open enrollment class, available to
| evening and summer students. That class was, well it as Assembly,
| so it was difficult. The homework assignments were odd, seemingly
| unrelated. At the midterm, the professor handed out a makefile
| that combined every assignment to date, and if you did your
| homework correctly, a mini version of Vi was produced. The rest
| of the class with polishing that version of Vi, all in assembly
| 11/780. Taught me one hell of a lot!
| porridgeraisin wrote:
| If you can recall, what were the individual assignments? Would
| love to understand how the modules added up
| bsenftner wrote:
| Now you've got me digging through archives, I've got all the
| homework assignments stored. I need to find someone with an
| exabyte tape reader...
| tilne wrote:
| If you do find someone I'd love to hear more as well.
| kps wrote:
| I'm now reminded of an unrelated mini-vi:
| https://github.com/ioccc-src/winner/blob/master/1991/ant/ant...
| beezle wrote:
| minor: Vax 11/780 was a minicomputer, though DEC itself refered
| to it as a 'supermini"
| amelius wrote:
| Does anyone know of a good Vim plugin for navigating Python code
| blocks? E.g. moving to the start/end of a block, or moving to the
| next block.
| teo_zero wrote:
| If I remember correctly the script runtime/ftplugin/python.vim
| remaps [[, [], ]], etc. to work with Python's idea of blocks.
|
| Besides, the plugin michaeljsmith/vim-indent-object defines a
| new text object ("i"), based on indentation levels.
| DriftRegion wrote:
| Mapping escape to caps-lock makes much more sense after looking
| at the ADM-3A keyboard layout. Cool write-up!
___________________________________________________________________
(page generated 2025-04-19 23:01 UTC)