You can see it here in Ritter vi on lines 83 et seq. of ex_vis.h . vi actually has three flavours of its 'open' mode, for cursor addressable video terminals, non-cursor addressable video terminals, and actual paper terminals.
There's an as-yet unfilled niche for the retrocomputeristas with genuine ADM-3s or (as someone pointed out) TI Silent 703s and suchlike to do a YouTube video showing Joy+Horton vi in its 3 open modes.
It's basically the answer to the question of how one does vi-like visual editing when the cursor cannot be moved to arbitrary locations on the terminal, or sometimes cannot even be moved upwards.
Amusing factoid: It's actually sort of the other way around. open mode was added to ex before visual mode was. visual mode is the answer to the question of how you can take advantage of an ability to move the cursor around arbitrarily.
VIM and STEVIE never implemented it. VIM makes :open do the same as :visual . nvi and nvi2 issue a 'not implemented' error for the :open nex command. Watcom vi does not even have :open . Nor do NeoVIM, nextvi, neatvi, and viless.
Mortice Kern vi has open mode. So does elvis version 2.
I mostly used it when I logged in over a 1200 baud modem. The terminal would have supported working full-screen, but it was just quicker to not keep the entire screen visible all the time (even though classic vi is already very efficient about screen updates).
Huh. So in open mode, ex basically works as if ed appended "p" to every text-editing command? Combined with "list" and "number" options, that sounds like a much more pleasant to use version of ed, even on a dumb "glass-tty".
It is more like a one-line visual mode, you can actually use the same commands as there. Depending on terminal capabilities (that's why there are apparently three submodes), you can move the cursor left and right, and insert and delete text. IIRC, I once somehow got it in a very limited "dumb terminal" mode, and it printed \ for every deleted character.
As an undergrad around 1984 I stumbled on some AT&T 3B2's in the computer lab and started to play. Knowing nothing of Unix (would have been ~ SVR3.x), I asked for help and the TA said something like "read the fine manual" as was customary. So I started off with "man something" and off we went, ending up at "man 1 vi", the glorious, pure original, none of this vim stuff...
Of course when I got onto the BSD VAX, someone set me straight and it was Emacs from there on..
I wish it took up more than 640 pixels on the left of my 1920 pixel screen. I changed the CSS of the body to be 900pt instead of 480, and it renders at 1200px wide, which looks a lot nicer to my eyes. Didn't bother trying to center it though, which would have improved it even more
That’s a feature. It lets your thumb scroll comfortably in a larger blank area so the content is always in view for you. There is no reason for things to be centered, it does not aid readability.
Just as impractical as expecting the user to use tiny windows on a 32" ultrawide. It's a literal example of "telling the user they are holding it wrong" being the wrong approach to the problems.
Yup, I hope every one agrees to leave proper justified text to LaTeX/ConTeXt/Typst/<your_favorite_typesetting_software>, doing such thing for HTML is still ugly and makes things harder to read
Mobile browsers are assuming you're looking at a legacy page optimized for desktops (widescreen) and have a relatively large virtual screen size by default. They expect you to manually zoom in as necessary. Adding this helps:
I started writing a more fleshed out vi compatibility mode for TextAdept earlier this year. As someone who understood the basics after going through :vimtutor multiple times but always struggled with the more "advanced" commands, there's no better way to actually grok vi than to just try to recreate it. It's pretty amazing how much Bill Joy managed to pack in. Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing, but there are also quite a few commands that I had never paid attention to (like _) that have subtle behaviors that sped up my editing even more. The hardest part about becoming proficient in vi is committing commands to muscle memory so you don't habitually fall back on hjkl.
> Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing
What do you mean by "roff/troff macros"?
EDIT: Ah, you're probably talking about the "section-wise" movements, defined in POSIX with language like "A line whose first character is a <period> and whose second and third characters match a two-character pair in the 'sections' edit option (see ex)" - that's the first time I've stumbled upon the 'sections' and 'paragraphs' options in the Vim manual ... Very quaint!
Yep, those are the ones! There's also the oddity of the [[ and ]] motions. In the POSIX standard, those are the only two-character motions. I was using a state-machine to implement motion commands, and that single command threw a wrench in the works. Of course, vim took two character commands and ran with it, so in vim [ can be followed by a whole host of characters that all do different things. Since g was not mapped in vi they also did the same thing there.
Is still around, at least for some values of "around".
Elvis, at its latest release (2.2.0) is a required part of Slackware, part of the A (essential system) package series. I have it installed on my system, alongside Plasma 6.7 and kernel 7.1.
I suppose, but you can only install it via the AUR or nixpkgs on linux, and 2 out of the 4 BSDs no longer have ports. Sure, you can compile from source but when it's that old I consider such a state effectively no longer around
I learned vi back in the day and have never really graduated to vim.
My favorite features are the ranges on the commands (like substitute or delete), piping the buffer into the bottomless utility of the classic UNIX command line, and the . do again command.
About the only vim feature I use today is being able to navigate while entering text, but even after all this time, that is not automatic to me.
I have used syntax coloring a couple of times, I find it particularly useful for XML, especially XML with chunks of XML commented out.
I can't think of any, but I can share some examples.
When shredding things like log files, or raw data file, being able to do things like:
:g/bad line/d
To delete all of the "bad lines". When manually paring down some files, you can use `ma` to do "Mark A" (vs `mb`, which is Mark B). So, I can be scrolling through the file, do the mark when I get to the top of a garbage section, and page or scroll or search to the next "keep" section, and then do `d'a` which means "delete to A", and so it removes all of the stuff I've skipped through.
Doing simple things like:
!Gformat (! to shell out, G for "the entire buffer", format is the program)
Which runs the entire buffer through the `format` command to wrap paragraphs. I don't necessarily need that feature in my editor, I have a utility that I can use instead.
Of course, you can use `!'a` to a mark. or `!/thing` to run current line to the next "thing" (use `?` for previous).
Banging to utilities is a nice way to develop a pipeline, you basically get to see stuff step by step. So instead of:
grep thing file | cut -f 1 | sort
You can vi the file, `!Ggrep thing`, "Yup!", `!G cut -f 1`, "Ok!", `!G sort` and easily see the intermediate steps. (Not recommended on enormous files, since the entire region is replaced.)
The `.` is great for `/word` to find a "word", `cwnew-word`, and apply it selectively. `n` to "search next", and it you like it, `.` to do the `cw` again. Otherwise, keep using `n` until you find the one you like.
And I have no problem running a chunk through a bang command to see what's what, only to just `u`ndo it. (With modern `vim`, you can undo that all the way back to the start if you're doing that pipeline thing.)
And, I would routinely do something like:
ma$%:'aw/tmp/x.x!vi other.txt then /wherever, :r /tmp/x.x
Mark A, `$` to EOL, `%` to closing brace (imagine a C function header), write from mark A to current line to /tmp/x.x, `!` to shell out to a new `vi` session, then read in the snippet.
Old school, single session, copy and paste. My /tmp is scattered with x.x, x.y, x.1, etc. files.
Along with regex replaces, this is 95% of how I use `vi`. I'm sure there's a bunch of other features, especially in `vim`, but these few bits are flexible and powerful enough to cover my needs. Since I haven't really been found "wanting", I'm not really "looking".
And it started because `vi` was a singular common denominator across all of the disparate UNIX minis I used to work on, so I just managed to work with what was available wherever I went.
I'm roughly at the same level. The main improvement of vim over vi is the infinite undo, and more recently the UTF-8 support. I like the more elaborate status line and the syntax colouring, and I actually have cpoptions set to "downgrade" a few (but not all) features to how they were in vi ( notably vx$ so text you're changing remains visible while you're typing over it, and Esc actually executes the command line).
On the rare occasions that I encounter non-Vim vi clones, I quickly run into missing features like these:
- deleting past the insertion point in insert mode
- visual mode
- split screen
- multiple buffers
- text objects
- macros
So even for people who don't care about Vim's syntax highlighting or autocomplete features, I'd assume real vi is a non-starter. I'd choose it over nano (no offence), but still.
Only Ritter vi is really a fork. All of the rest are clones, ground-up reimplementations not forked from the Joy+Horton code.
Of them, and discounting the extreme fringes like vi-likes that run on the BBC Micro, only STEVIE lacks :x, and its derivatives all added it in. All of the other clones from MKS onwards, even neatvi and nextvi, have :x .
I was just talking about a fun and largely forgotten feature of Joy+Horton vi elsewhere.
* https://mastodonapp.uk/@JdeBP/116793159030149624
You can see it here in Ritter vi on lines 83 et seq. of ex_vis.h . vi actually has three flavours of its 'open' mode, for cursor addressable video terminals, non-cursor addressable video terminals, and actual paper terminals.
There's an as-yet unfilled niche for the retrocomputeristas with genuine ADM-3s or (as someone pointed out) TI Silent 703s and suchlike to do a YouTube video showing Joy+Horton vi in its 3 open modes.
What is open mode?
Fortunately, I don't have to write up an explanation of this, as Joy and Horton already did.
* https://ex-vi.sourceforge.net/viin/paper-7.html#section53
It's basically the answer to the question of how one does vi-like visual editing when the cursor cannot be moved to arbitrary locations on the terminal, or sometimes cannot even be moved upwards.
Amusing factoid: It's actually sort of the other way around. open mode was added to ex before visual mode was. visual mode is the answer to the question of how you can take advantage of an ability to move the cursor around arbitrarily.
* https://www.oreilly.com/library/view/learning-the-vi/1565924...
VIM and STEVIE never implemented it. VIM makes :open do the same as :visual . nvi and nvi2 issue a 'not implemented' error for the :open nex command. Watcom vi does not even have :open . Nor do NeoVIM, nextvi, neatvi, and viless.
Mortice Kern vi has open mode. So does elvis version 2.
I mostly used it when I logged in over a 1200 baud modem. The terminal would have supported working full-screen, but it was just quicker to not keep the entire screen visible all the time (even though classic vi is already very efficient about screen updates).
Huh. So in open mode, ex basically works as if ed appended "p" to every text-editing command? Combined with "list" and "number" options, that sounds like a much more pleasant to use version of ed, even on a dumb "glass-tty".
It is more like a one-line visual mode, you can actually use the same commands as there. Depending on terminal capabilities (that's why there are apparently three submodes), you can move the cursor left and right, and insert and delete text. IIRC, I once somehow got it in a very limited "dumb terminal" mode, and it printed \ for every deleted character.
As an undergrad around 1984 I stumbled on some AT&T 3B2's in the computer lab and started to play. Knowing nothing of Unix (would have been ~ SVR3.x), I asked for help and the TA said something like "read the fine manual" as was customary. So I started off with "man something" and off we went, ending up at "man 1 vi", the glorious, pure original, none of this vim stuff...
Of course when I got onto the BSD VAX, someone set me straight and it was Emacs from there on..
Tangentially related, I wish more websites and blogs looked like this now. It's elegant and modern but simple.
I wish it took up more than 640 pixels on the left of my 1920 pixel screen. I changed the CSS of the body to be 900pt instead of 480, and it renders at 1200px wide, which looks a lot nicer to my eyes. Didn't bother trying to center it though, which would have improved it even more
Lacks centering, other than that I also found it enjoyable to look at.
That’s a feature. It lets your thumb scroll comfortably in a larger blank area so the content is always in view for you. There is no reason for things to be centered, it does not aid readability.
This only works on large enough tablets. On phones the page isn't readable without a 3x zoom.
Not a feature on a 32inch ultrawide.
Use smaller window
Use phone horizontally.
Much more practically, the best designs are the ones who don't demand of the user they be consumed in a single form across every scenario.
Horizontal phones haven’t been practical for a while. The weight balance is off and you are forced to use it two handed. You’ll look like a toddler.
Just as impractical as expecting the user to use tiny windows on a 32" ultrawide. It's a literal example of "telling the user they are holding it wrong" being the wrong approach to the problems.
To me, the justified text makes it an effortful read.
Yup, I hope every one agrees to leave proper justified text to LaTeX/ConTeXt/Typst/<your_favorite_typesetting_software>, doing such thing for HTML is still ugly and makes things harder to read
Breaks Firefox's reader mode.
Looks like dog shit on mobile.
I agree that this general style is good, just without some of this page's fuckups.
Chrome's too, but why? It's just plain HTML.
Mobile browsers are assuming you're looking at a legacy page optimized for desktops (widescreen) and have a relatively large virtual screen size by default. They expect you to manually zoom in as necessary. Adding this helps:
This matches the max-width specified by the CSS. However, a smaller viewport width might be appropriate to increase the text size on mobile.Safari reader mode on mobile works great. But then again, this is a site where you should not need it.
A 2007 article from sourceforge.net and it's not even throwback Thursday.
"Gunnar Ritter <gunnarr@acm.org> 2007-11-29"
It's been years since I heard the term "Throwback Thursday", funny that reading it here felt like a throwback in its own right ^_^
It's still very much alive.
I started writing a more fleshed out vi compatibility mode for TextAdept earlier this year. As someone who understood the basics after going through :vimtutor multiple times but always struggled with the more "advanced" commands, there's no better way to actually grok vi than to just try to recreate it. It's pretty amazing how much Bill Joy managed to pack in. Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing, but there are also quite a few commands that I had never paid attention to (like _) that have subtle behaviors that sped up my editing even more. The hardest part about becoming proficient in vi is committing commands to muscle memory so you don't habitually fall back on hjkl.
> Of course, if you're implementing POSIX vi, there are quite a few features that have aged poorly, like roff/troff macros and line-editing
What do you mean by "roff/troff macros"?
EDIT: Ah, you're probably talking about the "section-wise" movements, defined in POSIX with language like "A line whose first character is a <period> and whose second and third characters match a two-character pair in the 'sections' edit option (see ex)" - that's the first time I've stumbled upon the 'sections' and 'paragraphs' options in the Vim manual ... Very quaint!
Yep, those are the ones! There's also the oddity of the [[ and ]] motions. In the POSIX standard, those are the only two-character motions. I was using a state-machine to implement motion commands, and that single command threw a wrench in the works. Of course, vim took two character commands and ran with it, so in vim [ can be followed by a whole host of characters that all do different things. Since g was not mapped in vi they also did the same thing there.
I wish elvis was still around. I don't want everything vim has but I like syntax highlighting and other conveniences
See infobox.
* https://jdebp.uk/FGA/vi-family.html#elvis (https://news.ycombinator.com/item?id=48132452)
Is still around, at least for some values of "around".
Elvis, at its latest release (2.2.0) is a required part of Slackware, part of the A (essential system) package series. I have it installed on my system, alongside Plasma 6.7 and kernel 7.1.
I suppose, but you can only install it via the AUR or nixpkgs on linux, and 2 out of the 4 BSDs no longer have ports. Sure, you can compile from source but when it's that old I consider such a state effectively no longer around
> you can only install it via the AUR or nixpkgs on linux
I just said that it comes already installed (because is a required, essential part of the system) in Slackware.
Slackware is a Linux distribution, just as Arch or NixOS.
So, install Slackware, and elvis comes bundled and installed in your Linux.
I mean, if that's the case, then there's an argument to be made that SCCS is still a valid VCS because it comes with FreeBSD
I learned vi back in the day and have never really graduated to vim.
My favorite features are the ranges on the commands (like substitute or delete), piping the buffer into the bottomless utility of the classic UNIX command line, and the . do again command.
About the only vim feature I use today is being able to navigate while entering text, but even after all this time, that is not automatic to me.
I have used syntax coloring a couple of times, I find it particularly useful for XML, especially XML with chunks of XML commented out.
Any interesting reading on the second paragraph?
I can't think of any, but I can share some examples.
When shredding things like log files, or raw data file, being able to do things like:
To delete all of the "bad lines". When manually paring down some files, you can use `ma` to do "Mark A" (vs `mb`, which is Mark B). So, I can be scrolling through the file, do the mark when I get to the top of a garbage section, and page or scroll or search to the next "keep" section, and then do `d'a` which means "delete to A", and so it removes all of the stuff I've skipped through.Doing simple things like:
Which runs the entire buffer through the `format` command to wrap paragraphs. I don't necessarily need that feature in my editor, I have a utility that I can use instead.Of course, you can use `!'a` to a mark. or `!/thing` to run current line to the next "thing" (use `?` for previous).
Banging to utilities is a nice way to develop a pipeline, you basically get to see stuff step by step. So instead of:
You can vi the file, `!Ggrep thing`, "Yup!", `!G cut -f 1`, "Ok!", `!G sort` and easily see the intermediate steps. (Not recommended on enormous files, since the entire region is replaced.)The `.` is great for `/word` to find a "word", `cwnew-word`, and apply it selectively. `n` to "search next", and it you like it, `.` to do the `cw` again. Otherwise, keep using `n` until you find the one you like.
And I have no problem running a chunk through a bang command to see what's what, only to just `u`ndo it. (With modern `vim`, you can undo that all the way back to the start if you're doing that pipeline thing.)
And, I would routinely do something like:
Mark A, `$` to EOL, `%` to closing brace (imagine a C function header), write from mark A to current line to /tmp/x.x, `!` to shell out to a new `vi` session, then read in the snippet.Old school, single session, copy and paste. My /tmp is scattered with x.x, x.y, x.1, etc. files.
Along with regex replaces, this is 95% of how I use `vi`. I'm sure there's a bunch of other features, especially in `vim`, but these few bits are flexible and powerful enough to cover my needs. Since I haven't really been found "wanting", I'm not really "looking".
And it started because `vi` was a singular common denominator across all of the disparate UNIX minis I used to work on, so I just managed to work with what was available wherever I went.
I'm roughly at the same level. The main improvement of vim over vi is the infinite undo, and more recently the UTF-8 support. I like the more elaborate status line and the syntax colouring, and I actually have cpoptions set to "downgrade" a few (but not all) features to how they were in vi ( notably vx$ so text you're changing remains visible while you're typing over it, and Esc actually executes the command line).
On the rare occasions that I encounter non-Vim vi clones, I quickly run into missing features like these:
- deleting past the insertion point in insert mode
- visual mode
- split screen
- multiple buffers
- text objects
- macros
So even for people who don't care about Vim's syntax highlighting or autocomplete features, I'd assume real vi is a non-starter. I'd choose it over nano (no offence), but still.
vim with mouse frustrates the hell out of me.
Just give me basic vi, or a complete editor
`set compatible`?
Github mirror + some bugfixes
https://github.com/n-t-roff/heirloom-ex-vi/
:x is a vim feature, so this wouldn't support it, so you'll have to use :wq instead.
Incorrect.
:x is a vi feature, that was introduced by Mary Ann Horton to actual Joy+Horton vi in February 1980.
* https://code.illumos.org/plugins/gitiles/illumos-gate/+/refs...
Ritter's vi is derived from Joy+Horton vi. Illumos has the original.
Fascinating! I wonder what fork of vi I landed on that didn't have :x for me to have mis-picked-up that bit of trivia.
Only Ritter vi is really a fork. All of the rest are clones, ground-up reimplementations not forked from the Joy+Horton code.
Of them, and discounting the extreme fringes like vi-likes that run on the BBC Micro, only STEVIE lacks :x, and its derivatives all added it in. All of the other clones from MKS onwards, even neatvi and nextvi, have :x .
* https://jdebp.uk/FGA/vi-family.html
or ZZ to save and exit
28 years of vi and TIL about ZZ.
Thanks friend! ^_^
ZZ is the first vi command I learned. After typing vi and only seeing a column of ~s, I asked how do I get out of this thing. Someone answered - ZZ.
Did they say "zz" or specify [capital] "ZZ"?
They probably said Shift - ZZ
I just learnt it the other day, as well. Granted, it was from chapter 1 of "Learning the vi and vim Text Editors" but shhh
Repeat ZZ to save & exit if there are more files to edit
ZQ - discard & exit
text editors 5ever