is "vi" worth learning in 2022?

Here is a vi ref card: https://www.cheat-sheets.org/saved-copy/vi Reference Card (HP).pdf -- I found a few more but this was the best of the lot (IMHO).

Here is my EXINIT env. var (variations of which I have been using for last 40 years!):
:se ws ai sm sw=4| map ^K O/*^M *^M*/^[kA |map ^X !}fmt -p 60 61^M|map ^N :tagnext^M|map ^P :tagprev^M
Explanation left as an exercise for the reader!

More useful stuff including vi "tricks" here: http://www.faqs.org/faqs/editor-faq/vi/part1/ - also check out part2.
 
The reason why Nano is not a standard editor is because it was never meant to be one.

Nano by itself is just the clone of an older editor named Pico. Pico was created in 1992, and was the editor component taken out of the mail user agent Pine.

So in its origins Pico was meant to be an easy editor to write emails. Nothing more, nothing less. Also its key bindings were not modeled after Vi, Emacs or Wordstar, instead the author came up with his own ideas about it.

When the development of Pine became stale, and the license somewhat unclear, GNU Nano was created. This was a clone from scratch, and still is. Nowadays Nano has more features than Pico has to offer, most of them geared towards programming stuff.

vi on the other hand is around since 1976, and part of the POSIX standard (well some functionality). This is why it is on most distributions the standard editor, because its everywhere since decades. vi was already 16 years old when Pico came to be.

If nano is fine for you, then use it. Just be aware about if you want to get stuff done on many different installations in the wild vi will always be there, the others not. So knowing the basics of vi is definitely something every *NIX administrator should have.
 
T-Aoki, are you able to type Japanese in a terminal, (that is, say after boot, before X is started.) I've only tried that with fcitx-fbterm, and not in FreeBSD. I think this whole thread's been a bit done to death, though I keep contributing, but my wife often calls me a hypocrite. To sum up, it seems that both vi and ee are in base, so anyone running into trouble during, or right after, install, can use them, and it's a waste of already strained resources to try to figure out something else. So, leave all the other stuff, like vim and nano, as ports. Again, I don't really know nano, but isn't ee similar enough to nano so that someone who just knew nano could get by, at least until they got the network running and could install the port?
 
scottro said:
T-Aoki, are you able to type Japanese in a terminal, (that is, say after boot, before X is started.) I've only tried that with fcitx-fbterm, and not in FreeBSD. I think this whole thread's been a bit done to death, though I keep contributing, but my wife often calls me a hypocrite. To sum up, it seems that both vi and ee are in base, so anyone running into trouble during, or right after, install, can use them, and it's a waste of already strained resources to try to figure out something else. So, leave all the other stuff, like vim and nano, as ports. Again, I don't really know nano, but isn't ee similar enough to nano so that someone who just knew nano could get by, at least until they got the network running and could install the port?
Click to expand...
textproc/uim incorporates uim-fep which works on vty. But it must be killed before startx, as console (vty) is not considered as console by X while it is running.
And ee cannot accept UTF-8 as input, but it can display it and can edit ASCII parts of the file. In many cases, it is sufficient for casual editing that ee is enough. More complex works should need X and more powerful editors/word processors.

Correction:
ee can accept UTF-8 inputs on vty.
First UTF-8 texts are typed using uim-fep, the part looks corrupted.
But once scrolling out from editing area and back, it was displayed normally.
On terminals on X, the same behaviour.
Just a casua test, as I'm currently using fcitx-mozc and mozc-server is occupie by it (on X on the same computer), thus I could only input Hiragana while uim-fep is Japanese input mode.
 
scottro said:
To sum up, it seems that both vi and ee are in base, so anyone running into trouble during, or right after, install, can use them, and it's a waste of already strained resources to try to figure out something else.
Click to expand...

I've used ee for quick scripts, conf files and such since '98 so I'm biased. I prefer kwrite for programming or serious text, and pico (in alpine) for text email.

scottro said:
So, leave all the other stuff, like vim and nano, as ports. Again, I don't really know nano, but isn't ee similar enough to nano so that someone who just knew nano could get by, at least until they got the network running and could install the port?
Click to expand...

Sure, and ee's on-screen help (which you can turn off) makes it near impossible to not know what's what, and you only need to know one key (Esc) to get into or out of menus and commands, including 'help'.

Default config is to use emacs-style key bindings, even. As you say, getting by until there's more access.

People who prefer vi can just use it; I fail to see the problem.
 
Worth learning in 2024. Same as it ever was. Happy new year!

PS: But wait, there's more! With an extra day in February to learn even more!
 
bakul said:
Who reads manuals these days?
Click to expand...
You regard this as a positive development?

I remember reading the DEC networking hardware manuals for fun. They delved just enough into the theory so you could understand the details and design an enterprise networking system with an undergraduate liberal arts degree and one year of experience. I wish I still had the notes and diagrams I wrote for myself while I read them on vacation. Yes, my boss was very impressed when I got back, and I would've got a promotion if the corporate structure allowed it (it didn't), and a raise if they weren't starved for money (they were.) It didn't matter. I rely on that knowledge to this day, and it came for free with our hardware, which was excellent, by the way.

Unfortunately most tech companies have fired their documentation teams and outsourced to freelancers all over the world. The quality is horrendous nowadays. The good ones are just boring. The bad ones are incomplete and sometimes just plain wrong.

Yeah, I'm probably just an old man shouting at clouds. I do find it ironic when people complain about short attention spans in the young, but then want to make it as easy as possible to not pay attention to anything.

richardtoohey2 said:
I would make them use NetBeans.
Click to expand...
This made me chuckle. Thanks!
 
Forgot to mention.
textproc/uim itself does not contain input method (conversion engine) itself and need to install any of supported one separately, and some of them requires additional bridging software, for example, japanese/uim-mozc.
At the same time, clients which does not support (or dislike) XIM or gtk2, such as Qt5, requires input method module like textproc/uim-qt5. Note that there's not yet Qt6 support, unless Qt5 support works for it, too. Same as Gtk4. Not sure they are in development or not, as I basically using chinese/fcitx with japanese/fcitx-mozc. Although categorized as chinese, chinese/fcitx works fine on engines categorized as japanese.
 
I also (but not in console) use mozc. However, on my last port upgrade, fcitx-mozc had disappeared, though it's still in ports. Not sure what happened there, but as I use it infrequently these days, for now, I'm just using fcitx-anthy
 
scottro said:
I also (but not in console) use mozc. However, on my last port upgrade, fcitx-mozc had disappeard, though it's still in ports. Not sure what happened there, but as I use it infrequently these days, for now, I'm just using fcitx-anthy
Click to expand...
How do you pugrade fcitx-mozc?
With poudriere[-devel] jail + pkg upgrade?
Build on bare-metal environment with make && make deinstall reinstall clean or using such as ports-mgmt/pkg_replace, ports-mgmt/portupgrade or ports-mgmt/portmaster?
Or pkg upgrade using official build?

Recently devel/dbus upgrade hit the tree and my poudriere-devel jail on stable/14, amd64 forcibly rebuilt japanese/fcitx-mozc. If you are using official package, possibly it was just being rebuilt and temporarily dissapeared from repo, causing fcitx-mozc on your computer to be deintalled.
 
This is just on a home workstation-cum-server, and I use simple pkg upgrade. FreeBSD-14.0-RELEASE-p4.
I just ran pkg update and then pkg search and it's still not showing up. But from what you say, I'm guessing that will change soon. Thanks again.
 
scottro said:
fcitx-anthy
Click to expand...

japanese/fcitx-anthy (correct link) | <https://www.freshports.org/japanese/fcitx-anthy/#packages> packages

T-Aoki said:
fcitx-mozc
Click to expand...

japanese/fcitx-mozc | <https://www.freshports.org/japanese/fcitx-mozc/#packages> packages. Fallout for 140amd64:
The maintaner's most recent commit to the ports tree was nine months ago:
Where fallout is not an explanation, the guide below should help to find an explanation for the absence of a package.

forums.freebsd.org

Using package build records at pkg-status.freebsd.org

https://people.freebsd.org/~grahamperrin/pkg-status/ This brief guide includes: screenshots an explanation of why the latest option – not to be confused with packages from the main branch of the ports tree (familiarly known as latest) – is not reliable a hint about the current requirement to...
forums.freebsd.org forums.freebsd.org
 
grahamperrin said:
The maintaner's most recent commit to the ports tree was nine months ago:
Click to expand...
Not by the maintainer himself, most recent related commit is commit 5e342f86853071e530e07f126901e8dddc23c6f0 by Po-Chuan Hsieh which fixed PR 275768. japanese/fcitx-mozc is actually a slave port of japanese/mozc-server and build goes fine after this commit for me.
Possible cause would be I'm basically using devel/samurai instead of devel/ninja and use devel/ninja only when devel/samurai doesn't seem to work correctly with insufficient compatibility.
I have
## Use devel/samurai instead of devel/ninja EXCEPT FOR CHROMIUM .if !${.CURDIR:M/usr/ports/www/chromium*} && !${.CURDIR:M/usr/ports/www/webkit2-gtk4*} && !${.CURDIR:M/usr/ports/graphics/libjxl*} && !${.CURDIR:M/usr/ports/devel/libayatana-indicator*} DEFAULT_VERSIONS+= ninja=samurai .endif
in my /etc/make.conf.
 
scottro said:
I don't know where I read this, maybe I coined it. Everything is easy once you know how to do it.
Click to expand...
Yeeees... and that's also when you are in position to judge whether this thing you've just learned to use is actually lousy or not. Now VI is absolutely amazing in its effectiveness, flexibility etc. If it wasn't for "formatting" of the documents, I would absolutely do ALL the editing in VI. All things considered, it is amazing.

Is that a good expression of my feelings about vi text editor? I admire it as an excellent product and piece of work, among other things. Being somewhat of an engineer by nature (if not presently by profession), I have warm feelings for everything that is ingenious, effective, simple etc.
 
Jose said:
You regard this as a positive development?

I remember reading the DEC networking hardware manuals for fun. They delved just enough into the theory so you could understand the details and design an enterprise networking system with an undergraduate liberal arts degree and one year of experience. I wish I still had the notes and diagrams I wrote for myself while I read them on vacation. Yes, my boss was very impressed when I got back, and I would've got a promotion if the corporate structure allowed it (it didn't), and a raise if they weren't starved for money (they were.) It didn't matter. I rely on that knowledge to this day, and it came for free with our hardware, which was excellent, by the way.

Unfortunately most tech companies have fired their documentation teams and outsourced to freelancers all over the world. The quality is horrendous nowadays. The good ones are just boring. The bad ones are incomplete and sometimes just plain wrong.

Yeah, I'm probably just an old man shouting at clouds. I do find it ironic when people complain about short attention spans in the young, but then want to make it as easy as possible to not pay attention to anything.


This made me chuckle. Thanks!
Click to expand...
You're right. And it's not kind of "young vs old generation". It's really the world getting hastier every year in its race after... what???? Happiness? No way. Happiness is in , among other things, TAKING YOUR TIME, my goodness. Taking your time to read, educate yourself, meditate, do things of high quality.
Yea they talk today a lot about "USING your time effectively etc". See? They don't know any more how to USE your time effectively. In their imagination that would mean "succeed in doing as many things as possible during the (short!!!!) time you have between your meals and sleeping".

But hey, time is YOUR LIFE. If you've decided to spend a certain part of this life of yours accomplishing some task, why would you want to RUSH it??? That's crazy.
 
Charlie_ said:
Ther is Japanese MicroEmacs. japanese/ng
EUC, JIS and SJIS are supported.

MicroEmacs-based editors/uemacs supports utf.
Japanese utf is also available.
Help is displayed on the screen.
Click to expand...
Thanks for the info!
But unfortunately, the licenses of those could interfere with BSD 2/3 clause license. japanese/ng contains GNU Emacs GPL in its archive and editors/uemacs seems to be restricting commercial uses.These could avoid them to be included into base.
Currently I could find editors/turbo is licenced under MIT and seem to handle OK for UTF-8 (not heavily tested).
 
Charlie_ said:
BSD3CLAUSE editors/nvi2 seems to be able to edit CJK UTF-8.
Click to expand...
Actually, with my casual test, vi(1) in base could handle UTF-8 and it should be an older version of nvi. So whats needed would be fixing ee(1) for UTF-8 or introducing new BSD-compatible licensed alternative for ee(1).
Note that base vi(1) could expose some problem when conducted extensive tests. There are no description about UTF-8 if I'm not overlooked. And cursor dissapears when it is on UTF-8 characters and reappear when backed on ASCII equivalent characters.
 
I see that the nvi in base was upgraded from 1.79 to 2.1.1 in 2013.
I didn't know that because editors/nvi-m17n is still 1.79.
 
I would say vi isn't just worth learning, it's absolutely essential if you're serious about learning UNIX. Along with the shell, sed, awk, regular expressions, all the standard commands, the filesystem, etc. I would almost add perl to that list, although perl was a later addition.

Vi (and ed/ex) IS the unix system editor, as defined by POSIX. It's also a really good editor to use, very powerful, and repays study. It's easy to learn too, just use it for a few days and you will soon find it becomes second nature.

You might be thinking, what has that got to do with gnome/kde/web etc. The answer is that those things are not unix. They are all add-ons that have been added on top, later, even X11 is in that category, in fact X was designed to be operating system agnostic. If you want to see unix, switch to one of the virtual consoles. That's unix.
 
Last edited:
You must log in or register to reply here.
Back
Top