5 ms·

Last time I checked OpenBSD's vi didn't support utf8 - this is a show stopper in 2022.

petepete 5y ago
Vis looks like a very minimal but thoroughly modern alternative. https://github.com/martanne/vis https://github.com/martanne/vis
trasz 5y ago
I wonder if they could merge back utf8 patches from FreeBSD.
- 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.
john-aj 5y ago
Indeed. Nvi, which was recommended elsewhere in the thread, supports UTF-8 and is my preferred vi clone. (Actually, OpenBSD vi is an old version of nvi without UTF-8 support.)
- 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 implementations descend from the late itojun's (http://www.itojun.org/itojun.html http://www.itojun.org/itojun.html) Nvi-m17n project (archived at https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files). A paper was presented at USENIX99 (http://www.usenix.org/events/usenix99/full_papers/hagino/hagino.ps http://www.usenix.org/events/usenix99/full_papers/hagino/hag...) describing the work, which was actually developed as part of the KAME project.
anthk 5y ago
You have nvi2 in ports.
- ruhrharry 5y ago
  Yes, and also vim and other vi clones. But what is the point of having a secure and integrated OS if you have to pull software from ports (which are not so thoroughly audited and tested as the main OS)? One point of using BSD is (so the BSD people say) to have an operating system where everything comes from the same team - kernel and userland, unlike Linux where kernel and userland comes from dozens if not hundreds of different origins. But if you start to use arbitrary ports in BSD your OS is not much better than Linux in that regard
  - salmo 5y ago
    Historically, this is why basic vi (of whatever flavor) was so popular. I could hop on any Unix and it was there OOB. I dealt with some mixed set of Solaris, BSD, HP-UX, Irix, Tru64, AIX, and Linux for so long. For a host I did primary development on, I’d install vim (visual mode and then syntax highlighting was so nice). But we managed config centrally with idempotent scripts that handled the differences (like no getent on HP-UX). We did have to install ksh88 or a clone everywhere to get a stable consistent shell. GNU was flaky on so many platforms then. Vi was always there for those WTF scenarios, less as a primary programming editor. And it is so nice on slow connections, where repainting the whole screen for every keystroke sucked. It really annoyed me when Linuxes dropped the basic vi everywhere in favor of nano. I’d be fine with nano as a default for accessibility, but at least have some vi in my path. Our standard images include it, but I always forget when I’m testing/debugging locally with Vagrant or a Docker image. Vi is always a little weird. I don’t think any 2 people use it the same. Everyone has their own go-to set of commands. Pairing with grey beards influenced me so much. I actually started with emacs in college, but real life with 1,000s of servers forced the change. I don’t have the muscle memory for it anymore and have no desire to go back. Nowadays my local neovim config is almost VSCode. But I still like VSCode-ish in vi more than vi-ish in VSCode. I tried, but inevitably do something that VSCode’s vim plug-in doesn’t support. I do use go more and more for complex stuff, but often am forced back to shell due to old kernels still out there which hurts my soul.
geokon 5y ago
I look forward to config files in right to left Hebrew Or maybe Arabic so the characters flow into each other
- bonzini 5y ago
  No need to wait, I'm sure many people have written their name in their native RTL script for git's "user.name" configuration key.
  - 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 byte-level. Improvements are in order, and should be made, but the mere inability to visually render multibyte characters is not always a showstopper.
  - geokon 5y ago
    Do they right-align their command lines and files? Or once the Arabic exceeds 50% the alignment of the buffer flips? :)
- selfhoster11 5y ago
  Or it could be just as simple as me jotting down some notes in my native language, which includes such exotic characters as ę and ą. You know, so I don't have to go back to using a code page like back in good old DOS days, that I'm actually too young to have lived through.
doingtheiroming 5y ago
Is it not a feature given how many security issues come out of parsing? There is virtue in the thing you’ll edit files with as root being as simple as you can make it.
throwawayboise 5y ago
It isn't for everyone. I have never come across a real need for more than standard ASCII in any of my work. It absolutely isn't needed for managing unix config files, which is the primary use case for "lightweight" editors like this.
- selfhoster11 5y ago
  Congratulations on English being the one and only language you use to make quick notes, then. I personally mix in words from my native language wherever I need an extra bit of semantic precision, and I'd rather not have to switch between editors to do so.
  - kQq9oHeAz6wLLS 5y ago
    Not to sound dismissive, but that is a rather niche use case
    - selfhoster11 5y ago
      For multilinguals (which is over half of the world's population), throwing in terms from another language or entirely switching to a different language mid-sentence during a conversation is entirely normal. I can't imagine it being that rare in personal notes.
      - kQq9oHeAz6wLLS 5y ago
        Sure, but how many of that number are keeping personal notes in vi?
        selfhoster11 5y ago
        Presumably, any number that prefer a terminal based workflow, or have the Vi key scheme burned into muscle memory. Or those that prefer an ultra-minimalist text editor for writing. Just a decade ago, it was almost a meme that the Emacs and Vi factions fought over which editor is better. I imagine that those that truly bought into the Vi ecosystem/fandom use it in preference to other available options.

Vis looks like a very minimal but thoroughly modern alternative. https://github.com/martanne/vis https://github.com/martanne/vis

trasz 5y ago

I wonder if they could merge back utf8 patches from FreeBSD.

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.

john-aj 5y ago

Indeed. Nvi, which was recommended elsewhere in the thread, supports UTF-8 and is my preferred vi clone. (Actually, OpenBSD vi is an old version of nvi without UTF-8 support.)

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 implementations descend from the late itojun's (http://www.itojun.org/itojun.html http://www.itojun.org/itojun.html) Nvi-m17n project (archived at https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files https://cgit.freebsd.org/ports/tree/editors/nvi-m17n/files). A paper was presented at USENIX99 (http://www.usenix.org/events/usenix99/full_papers/hagino/hagino.ps http://www.usenix.org/events/usenix99/full_papers/hagino/hag...) describing the work, which was actually developed as part of the KAME project.

anthk 5y ago

You have nvi2 in ports.

ruhrharry 5y ago
Yes, and also vim and other vi clones. But what is the point of having a secure and integrated OS if you have to pull software from ports (which are not so thoroughly audited and tested as the main OS)? One point of using BSD is (so the BSD people say) to have an operating system where everything comes from the same team - kernel and userland, unlike Linux where kernel and userland comes from dozens if not hundreds of different origins. But if you start to use arbitrary ports in BSD your OS is not much better than Linux in that regard
- salmo 5y ago
  Historically, this is why basic vi (of whatever flavor) was so popular. I could hop on any Unix and it was there OOB. I dealt with some mixed set of Solaris, BSD, HP-UX, Irix, Tru64, AIX, and Linux for so long. For a host I did primary development on, I’d install vim (visual mode and then syntax highlighting was so nice). But we managed config centrally with idempotent scripts that handled the differences (like no getent on HP-UX). We did have to install ksh88 or a clone everywhere to get a stable consistent shell. GNU was flaky on so many platforms then. Vi was always there for those WTF scenarios, less as a primary programming editor. And it is so nice on slow connections, where repainting the whole screen for every keystroke sucked. It really annoyed me when Linuxes dropped the basic vi everywhere in favor of nano. I’d be fine with nano as a default for accessibility, but at least have some vi in my path. Our standard images include it, but I always forget when I’m testing/debugging locally with Vagrant or a Docker image. Vi is always a little weird. I don’t think any 2 people use it the same. Everyone has their own go-to set of commands. Pairing with grey beards influenced me so much. I actually started with emacs in college, but real life with 1,000s of servers forced the change. I don’t have the muscle memory for it anymore and have no desire to go back. Nowadays my local neovim config is almost VSCode. But I still like VSCode-ish in vi more than vi-ish in VSCode. I tried, but inevitably do something that VSCode’s vim plug-in doesn’t support. I do use go more and more for complex stuff, but often am forced back to shell due to old kernels still out there which hurts my soul.

geokon 5y ago

I look forward to config files in right to left Hebrew Or maybe Arabic so the characters flow into each other

bonzini 5y ago
No need to wait, I'm sure many people have written their name in their native RTL script for git's "user.name" configuration key.
- 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 byte-level. Improvements are in order, and should be made, but the mere inability to visually render multibyte characters is not always a showstopper.
- geokon 5y ago
  Do they right-align their command lines and files? Or once the Arabic exceeds 50% the alignment of the buffer flips? :)
selfhoster11 5y ago
Or it could be just as simple as me jotting down some notes in my native language, which includes such exotic characters as ę and ą. You know, so I don't have to go back to using a code page like back in good old DOS days, that I'm actually too young to have lived through.

doingtheiroming 5y ago

Is it not a feature given how many security issues come out of parsing? There is virtue in the thing you’ll edit files with as root being as simple as you can make it.

throwawayboise 5y ago

It isn't for everyone. I have never come across a real need for more than standard ASCII in any of my work. It absolutely isn't needed for managing unix config files, which is the primary use case for "lightweight" editors like this.

selfhoster11 5y ago
Congratulations on English being the one and only language you use to make quick notes, then. I personally mix in words from my native language wherever I need an extra bit of semantic precision, and I'd rather not have to switch between editors to do so.
- kQq9oHeAz6wLLS 5y ago
  Not to sound dismissive, but that is a rather niche use case
  - selfhoster11 5y ago
    For multilinguals (which is over half of the world's population), throwing in terms from another language or entirely switching to a different language mid-sentence during a conversation is entirely normal. I can't imagine it being that rare in personal notes.
    - kQq9oHeAz6wLLS 5y ago
      Sure, but how many of that number are keeping personal notes in vi?
      - selfhoster11 5y ago
        Presumably, any number that prefer a terminal based workflow, or have the Vi key scheme burned into muscle memory. Or those that prefer an ultra-minimalist text editor for writing. Just a decade ago, it was almost a meme that the Emacs and Vi factions fought over which editor is better. I imagine that those that truly bought into the Vi ecosystem/fandom use it in preference to other available options.